Subject: Re: [boost] Request for interest in the new Synchro library
From: Dmitry Goncharov (dgoncharov_at_[hidden])
Date: 2009-02-17 04:54:21
> I would like to know if the Boost community is interested in the Synchro library. Of course there is a lot of work to do, but I think that there is enough material to start a discussion on the approach.
> I'd appreciate it if people could take a look, test it on their compiler and give me some feedback.
> The library is available at Boost Sandbox: https://svn.boost.org/svn/boost/sandbox/synchro and
> Boost Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=synchro.zip&directory=Concurrent%20Programming&
> that iIncludes every thing on the Sandbox + Html documentation
> Some examples use Boost.Interthreads also (available on the vault and the sandbox).
> This library is a compilation of what I have found in the literature not yet present in Boost. My main concern has been to boostify all these ideas in a coherent way. Next follows an overview of the library features:
> Boost.Synchro provides:
> * A uniform usage of Boost.Thread and Boost.Interprocess synchronization mechanisms based on lockables(mutexes) concepts and locker(guards) concepts.
> o lockables traits and lock generators,
> o lock adapters of the Boost.Thread and Boost.Interprocess lockable models,
> o locker adapters of the Boost.Thread and Boost.Interprocess lockers models,
> o complete them with the corresponding models for single-threaded programs: null_mutex and null_condition classes,
> o locking families,
> o semaphore,
> o condition_lockable lock which put together a lock and its associated conditions.
> * A coherent exception based timed lock approach,
> * A rich palette of lockers as
> o strict_locker, nested_strict_locker,
> o condition_locker,
> o reverse_locker, nested_reverse_locker,
> o locking_ptr, on_dereference_locking_ptr,
> o externally_locked,
> * A polymorphic lockable hierarchy.
> * High-level abstractions for handling more complicated synchronization problems, including
> o monitor for guaranteeing exclusive access to an object, and
> o a so-called rendezvous mechanism for handling direct communication between objects concurrent_components via ports using an accept-synchronize protocol based on the design of the concurrency library in the Beta language.
> On going work
> * array_locker and tuple_locker locker containers.
> * A complement to the already present in Boost.Thread lock, try_lock free functions:
> o lock_until, lock_for, try_lock_until, try_lock_for
> Best regrads,
> Vicente Juan Botet EscribÃ¡
I am interested in a binary semaphore, which is a semaphore with a count
0 or 1 only. No matter how many times it was posted the count doesn't
boost.interprocess doc mentions that the semaphore from
boost.interprocess can be binary if you initialize it with 1. However,
if you post that semaphore twice the count increases twice as well.
What type of semaphore are you planning to have in your library?