Boost.Interprocess uses the Windows COM library to implement some features and initializes it with concurrency model COINIT_APARTMENTTHREADED. If the COM library was already initialized by the calling thread for another concurrency model, Boost.Interprocess handles this gracefully and uses COM calls for the already initialized model. If for some reason, you want Boost.Interprocess to initialize the COM library with another model, define the macro BOOST_INTERPROCESS_WINDOWS_COINIT_MODEL before including Boost.Interprocess to one of these values:

Shared memory (shared_memory_object) is implemented in Windows using memory mapped files, placed in a shared directory in the shared documents folder (SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData). This directory name is the last bootup time obtained via Registry values of the Session Manager. This behaviour is the default since Boost 1.74.

Old Boost.Interprocess versions (until Boost 1.48 ) used COM calls (via macro BOOST_INTERPROCESS_BOOTSTAMP_IS_LASTBOOTUPTIME) but that timestamp was unreliable in Virtual Machines and time adjustements. Next versions until (Boost 1.74) used EventLog startup event as timestamp, but several users discovered this event could be absent in the Event Log if the system was up for a long time. You can force this Event Log based timestamp defining BOOST_INTERPROCESS_BOOTSTAMP_IS_EVENTLOG_BASED.

In any error case (shared documents folder is not defined or bootup time could not be obtained), the library throws an error. You still can use Boost.Interprocess defining your own directory as the shared directory. When your shared directory is a compile-time constant, define BOOST_INTERPROCESS_SHARED_DIR_PATH (and BOOST_INTERPROCESS_SHARED_DIR_WPATH in Windows systems) when using the library and that path will be used to place shared memory files. When you have to determine the shared directory at runtime, define BOOST_INTERPROCESS_SHARED_DIR_FUNC and implement the following functions

namespace boost {
    namespace interprocess {
        namespace ipcdetail {
            void get_shared_dir(std::string &shared_dir);
            //wstring overload is only needed for Windows systems
            void get_shared_dir(std::wstring &shared_dir);
        }
    }
}

If BOOST_USE_WINDOWS_H is defined, <windows.h> and other windows SDK files are included, otherwise the library declares needed functions and structures to reduce the impact of including those heavy headers.

On systems without POSIX shared memory support, shared memory objects are implemented as memory mapped files, using a directory placed in "/tmp" that can include (if BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME is defined) the last bootup time (if the OS supports it). As in Windows, in any error case obtaining this directory the library throws an error . When your shared directory is a compile-time constant, define BOOST_INTERPROCESS_SHARED_DIR_PATH when using the library and that path will be used to place shared memory files. When you have to determine the shared directory at runtime, define BOOST_INTERPROCESS_SHARED_DIR_FUNC and implement the function

namespace boost {
    namespace interprocess {
        namespace ipcdetail {
            void get_shared_dir(std::string &shared_dir);
        }
    }
}

The committed address space is the total amount of virtual memory (swap or physical memory/RAM) that the kernel might have to supply if all applications decide to access all of the memory they've requested from the kernel. By default, Linux allows processes to commit more virtual memory than available in the system. If that memory is not accessed, no physical memory + swap is actually used.

The reason for this behaviour is that Linux tries to optimize memory usage on forked processes; fork() creates a full copy of the process space, but with overcommitted memory, in this new forked instance only pages which have been written to actually need to be allocated by the kernel. If applications access more memory than available, then the kernel must free memory in the hard way: the OOM (Out Of Memory)-killer picks some processes to kill in order to recover memory.

Boost.Interprocess has no way to change this behaviour and users might suffer the OOM-killer when accessing shared memory. According to the Kernel documentation, the Linux kernel supports several overcommit modes. If you need non-kill guarantees in your application, you should change this overcommit behaviour.

Starting from FreeBSD 11, declares the macro _POSIX_THREAD_PROCESS_SHARED. However, the default behavior is different from the one on Linux. If you want to use this feature, according to the man page of libthr(3), you should check sysctl's kern.ipc.umtx_vnode_persistent:

If you want mapped files to remain useful after the last handle is closed, set this variable to 1.

Boost.Interprocess uses POSIX shared memory in MacOS to implement shared memory classes in MacOS.

But sandboxed apps cannot use System V (XSI) semaphores and POSIX semaphores and shared memory can't be used by default. However, by specifying an entitlement that requests membership in an application group, an app can use these technologies to communicate with other members of that application group.

Please see Apple documentation for limitations and guide on how to use interprocess communications on sandboxed applications.

Win32 version of shared mutexes and shared conditions are based on "spin and wait" atomic instructions. This leads to poor performance and does not manage any issues like priority inversions. We would need very serious help from threading experts on this. And I'm not sure that this can be achieved in user-level software. Posix based implementations use PTHREAD_PROCESS_SHARED attribute to place mutexes in shared memory, so there are no such problems. I'm not aware of any implementation that simulates PTHREAD_PROCESS_SHARED attribute for Win32. We should be able to construct these primitives in memory mapped files, so that we can get filesystem persistence just like with POSIX primitives.

Currently Interprocess only allows char based names for basic named objects. However, several operating systems use wchar_t names for resources (mapped files, for example). In the future Interprocess should try to present a portable narrow/wide char interface. To do this, it would be useful to have a boost wstring <-> string conversion utilities to translate resource names (escaping needed characters that can conflict with OS names) in a portable way. It would be interesting also the use of boost::filesystem paths to avoid operating system specific issues.

Boost.Interprocess does not define security attributes for shared memory and synchronization objects. Standard C++ also ignores security attributes with files so adding security attributes would require some serious work.

Boost.Interprocess offers a process-shared message queue based on Boost.Interprocess primitives like mutexes and conditions. I would want to develop more mechanisms, like stream-oriented named fifo so that we can use it with a iostream-interface wrapper (we can imitate Unix pipes).

C++ needs more complex mechanisms and it would be nice to have a stream and datagram oriented PF_UNIX-like mechanism in C++. And for very fast inter-process remote calls Solaris doors is an interesting alternative to implement for C++. But the work to implement PF_UNIX-like sockets and doors would be huge (and it might be difficult in a user-level library). Any network expert volunteer?