Boost.Interprocess uses the Windows
COM library to implement some features and initializes it with concurrency
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
before including Boost.Interprocess
to one of these values:
Shared memory (
is implemented in windows using memory mapped files, placed in a 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 COM calls),
so that each bootup shared memory is created in a new folder obtaining
kernel persistence shared memory.
Unfortunately, due to COM implementation related errors, in Boost 1.48
& Boost 1.49 the bootup-time folder was dumped and files were directly
created in shared documents folder, reverting to filesystem persistence
shared memory. Boost 1.50 fixed those issues and recovered bootup time
directory and kernel persistence. If you need to reproduce Boost 1.48
& Boost 1.49 behaviour to communicate with applications compiled
with that version, comment
directive in the Windows configuration part of
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.
Many people have contributed with ideas and revisions, so this is the place to thank them:
message_queuewith a circular buffer index (the old behavior used an ordered array, leading to excessive copies). This should greatly increase performance but breaks ABI. Old behaviour/ABI can be used undefining macro
message_queueinsertion time avoiding priority search for common cases (both array and circular buffer configurations).
mapped_regionas it has no practical utility and
m_offsetmember was not for anything else.
managed_shared_memory. as it is unspecified according to POSIX: "The effect of msync() on a shared memory object or a typed memory object is unspecified" .
#define BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIMEin the windows configuration part to get Boost 1.48 & Boost 1.49 behaviour.
mapped_region::flushinitiates disk flushing but does not guarantee it's completed when returns, since it is not portable.
named_semaphorenow implemented more efficiently with atomic operations.
shared_memory_object::removehas now POSIX
file_mapping::removewas added to obtain POSIX
unlinksemantics with mapped files.
BOOST_INTERPROCESS_FORCE_GENERIC_EMULATIONmacro option to force the use of generic emulation code for process-shared synchronization primitives instead of native POSIX functions.
boost::posix_time::pos_infvalue is now handled portably for timed functions.
const_iteratorin containers to keep up with the draft of the next standard.
voidreturn types from
mapped_regionthe mode used to create it.
shared_ptris movable and supports aliasing.
unique_ptr. Added explanations and examples of these smart pointers in the documentation.
pointeras an smart pointer. This increases performance and improves compilation times.
named_semaphorewith POSIX named semaphores in systems supporting that option.
named_conditionhas been accordingly changed to support interoperability with
mapped_regionin UNIX when mapping address was provided but the region was mapped in another address.
allocate_manyfunctions to managed memory segments.
get_instance_typefunctions to managed memory segments.
segment_managerto avoid code bloat associated with templated instantiations.
deque::erase(), they were declared private.
deque::erase(). Thanks to Steve LoBasso.
atomic_dec32(). Thanks to Glenn Schrader.
boost::has_trivial_destructor. This optimization avoids calling destructors of elements that have a trivial destructor.
has_trivial_destructor_after_movetrait. This optimization avoids calling destructors of elements that have a trivial destructor if the element has been moved (which is the case of many movable types). This trick was provided by Howard Hinnant.
deallocate_free_chunks()) to manually deallocate completely free chunks from node allocators.
shared_memory_object.hppheader instead of
mapped_regionconstructor no longer requires classes derived from memory_mappable, but classes must fulfill the MemoryMappable concept.
Some useful references about the C++ programming language, C++ internals, shared memory, allocators and containers used to design Boost.Interprocess.
There are some Interprocess features that I would like to implement and some Boost.Interprocess code that can be much better. Let's see some ideas:
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?