Hi to all, I've uploaded to the boost repository and Boost.Vault/Concurrent Programming: (http://boost-consulting.com/vault/index.php?directory=Concurrent%20Programmi...) the first Boost.Interprocess version with documentation. The previous code had no documentation so this is the biggest change. You can find online documentation here: http://ice.prohosting.com/newfunk/boost/libs/interprocess The new documentation tries to explain better the basic operating system wrappers, like synchronization primitives, shared memory objects, essential file mapping, etc... The second part of the documentation is taken and adapted from Shmem. The library still needs some breaking changes, specially, error reporting with proposed boost system exception library. Since Boost.Interprocess offers a wide range of operating system primitives, I want to use the same error report machinery as Boost.Filesystem and Boost.Asio. For the moment, Boost.Interprocess throws interprocess_exception on error. Interesting additions are new named synchronization utilities and the use of move semantics to implement lock transfers, following this proposal: http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html Boost.Inteprocess implements upgradable_mutex (a read-write mutex on steroids) with the addition of timed functions and several scoped lock types. You can read about them in the proposal and in Boost.Interprocess documentation: * Upgradable mutex http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interproc... * Lock Transfers http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interproc... The move semantics emulation is custom code, but obviously, I'm very interested in a Boost.Move library and I will update the code to use it if that's included in Boost. If the C++ committee chooses a different mutex proposal as the way to go, or modifies this proposal, I will adapt Boost.Interprocess to the new interface. *** Future work *** * Atomic initializations I'm still working on this. My first try has failed, because file locking is not thread-safe in POSIX (the file descriptor is a process-wide resource, and file locking functions don't mutually exclude threads from the same process). Adding an static thread-mutex in the code would not allow using Boost.Interproces in dll-s. Flyweight can't be used, because it relies on the old Boost.Interprocess global mutex to achieve this, so this is a recursive problem ;-). We'll see. * scoped_ptr vs. unique_ptr and move semantics Good old Shmem has it's own scoped_ptr (that has a custom deleter to be able to erase dynamically allocated shared memory objects) and Boost.Interprocess still has it, but I would like to drop it and use a unique_ptr that could be placed in shared memory. This can also substitute scoped_ptr for RAII tasks and we could use it to construct containers of unique_ptr's and avoid tedious hand-deletions. Move semantics could also be applied to other types, like shared memory strings and vectors. A vector of strings in shared memory with move semantics and in-place expansion should be killer. * Allocation algorithm I would want to add the option to allocate memory with alignment restrictions, so that we can request N bytes of memory with at least A byte alignment. This is a usual user request and I think that can be used for some new tricks. ...And of course, I must change the documentation according to the review. Thanks to all for all bug reports! Regards, Ion