[Boost-users] [shmem-interprocess] Shmem 0.93 and update on Interprocess

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-06-10 16:21:23

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%20Allocators.html

-> 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