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