Hi to all, I've just uploaded to Boost Vault a new Shmem bugfix version (0.93) with bugfixes to make Shmem MinGw friendly (props to Jan Stetka). Library and documentation download: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Memory Online documentation: http://ice.prohosting.com/newfunk/boost/libs/shmem/ //////////////////////////////////////////////////////////// Update on Interprocess: -> Due to Shmem problems with shared memory/named mutex/name semaphore lifetime between POSIX/Windows. I've decided to change Shmem approach (emulation of Windows lifetime behavior in POSIX with reference counting) to a POSIX lifetime (explicit unlinking shared memory). This means that I have to rework all main classes to achieve POSIX persistence semantics in Windows even when a process crashes. This will require using memory mapped files to emulate shared memory (with some tricks to avoid performance problems with file-memory synchronization if it's possible). I think that this approach will be much more portable than the Shmem approach. -> I'm also experimenting with a new allocator with expand-in place capabilities to allow realloc-like features in shared memory containers. The first results are encouraging both in size savings and speed improvements. This expand in place features are based on a paper I plan to present as a ISO C++ proposal based on N1953. You can find the current draft here, if you want to make some comments: http://ice.prohosting.com/newfunk/proposals/nXXXX%20Improving%20STL%20Alloca... -> I'm also experimenting with a new reduced mutex interface (basically condensing shared_mutex, shared_try_mutex and shared_timed_mutex in a single interprocess_mutex type. Something in the line of the draft "Simplifying And Extending Mutex and Scoped Lock Types For C++ Multi-Threading Library" that you can find here: http://ice.prohosting.com/newfunk/proposals/ I'm also trying to implement a process-shared version of Howard Hinnant's upgradable_mutex class described here: http://home.twcny.rr.com/hinnant/cpp_extensions/rw_perf.html http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html I still have some bugs in my upgradable_mutex implementation that I plan to solve soon. I think that this enhazed rw mutex is a winner for Interprocess. -> I'm adding a new mutex type: file_lock. The classic UNIX fcntl / Windows FileLockEx file locking is an interesting addition to Interprocess since both in POSIX and Windows, the lock is automatically unlocked by the OS when the process ends/crashes. This can help problematic Shmem atomic creation+initialization functions if the process crashes executing the atomic code. File locking is also many times easier to use than named mutexes or shared memory + process shared mutexes, specially for simple locking. That's all. Thanks for your patience! Regards, Ion