[boost] [interprocess] New snapshot and some explanations

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-08-06 06:53:55

Hi to all,

I've uploaded to the boost repository and Boost.Vault/Concurrent 
Programming:

(http://boost-consulting.com/vault/index.php?directory=Concurrent%20Programming)

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/interprocess/upgradable_mutexes.html

* Lock Transfers

http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interprocess/lock_conversions.html

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