Boost logo

Boost :

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-03-17 18:16:02


I'm defining a class Locally Unique Identifier (see that has a locking

This locking policy needs to define a mutex_type and a scoped_lock types.
This could be null_locking_policy for monothreaded usage,
thread_locking_policy for multi-threaded access and process_locking_policy
for multi-process access.

The problem is that when I try to initialize the scoped lock with a
try_to_lock the types and variables are differents, even if both mùean the
same. And so I need to add a function try_to_lock in the policy.

struct thread_locking_policy {
    typedef boost::mutex mutex_type;
    typedef boost::mutex::scoped_lock scoped_lock;
    static const boost::try_to_lock_t try_to_lock() {return
struct process_locking_policy {
    typedef boost::interprocess::interprocess_mutex mutex_type;
    typedef boost::interprocess::scoped_lock<mutex_type> scoped_lock;
    static boost::interprocess::detail::try_to_lock_type try_to_lock()
    return boost::interprocess::try_to_lock;

IMO we need to armonize the threads and interprocess synchronization
I don't know where these types and variables could be, but we need that both
libraries use the same type and variable.

Anyway, these trivial classes will be redone by each user defining a class
that manage the synchronization in a wide context. Is there an interest in
these locking policies classes. We can add recursive_thread_locking_policy
and recursive_process_locking_policy . Where these classes could be placed.

Why not in an new boost/sync directory?

Please, let me know if there is a better solution already present on boost.

Vicente Juan Botet Escriba

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