Boost logo

Boost :

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


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:

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:

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

* Upgradable mutex

* Lock Transfers

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!



Boost list run by bdawes at, gregod at, cpdaniel at, john at