Boost logo

Boost :

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-10 07:29:53

Hi Phil,

----- Original Message -----
From: "Phil Endecott" <spam_from_boost_dev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, May 09, 2008 7:06 PM
Subject: Re: [boost] [thread] is there an interest onthis
unique_to_shared_mutex_adapter class?

> vicente.botet wrote:
>> template <typename Lockable>
>> class shared_lockable_adapter
>> {
>> shared_lockable_adapter(Lockable& mtx): mtx_(mtx) {}
>> ~shared_lockable_adapter() {}
>> void lock_shared() {mtx_.lock();}
>> void unlock_shared() {mtx_.unlock();}
>> bool try_lock_shared() { return mtx_.try_lock();}
>> void lock() {mtx_.lock();}
>> void unlock() {mtx_.unlock();}
>> bool try_lock() { return mtx_.try_lock();}
>> // other functions ....
>> private:
>> Lockable& mtx_;
>> };
> So this is a trivial adapter that makes a shared mutex that can't
> actually be shared.

Yes you are right, you will not allow shared owneship, but that allows to
use generic functions that works for a ExclusiveLockable and than can
perform better for a SharedLocable mutex, and it is up to the user to choose
between an adaptation of mutex or a shared_mutex. If the performances are
obtained using the SharedLockable extensions the function must be defined in
terms of this concept.

Conside an application that must use a lot of some classes and algorithms
and preserv a transaction behaviour, so some kind of common mutex will be
used to synchonize externally all this classes and algorithms. Supose that
some classes or algorithms have been templated with a SharedLockable. Even
if the SharedLockable classes and algorithms can perform better with
shared_mutex when isolated, this do not implies that the whole application
will perform better. This is where the shared_lockable_adapter can be used.
All this depends on the user application.

> It would also be possible, I think, to make an adapter that actually
> creates a shared mutex from a normal one. I've never had to write a
> read/write mutex but I guess that this is how they are implemented
> internally.

The better adapter will be to take a shared_mutex directly as it can be used
directly on contexts waiting a ExclusiveLockable.

> There are various usage scenarios. For example, I may have a generic
> algorithm that really needs a shared lock that can be shared, i.e. it
> creates threads that must run concurrently. If I concept-check that
> the passed mutex is a SharedLockable, but it's actually your adaptor,
> I'll get a runtime deadlock. Maybe we need some more fine-grained
> concepts to express these requirements.

Surely you are right. The adaptor will limit the concurrence. Only if the
thread taking the shared-lock (exclusive lock with the adaptor) needs some
kind of active communication from the other thread while the mutex is
locked, we will have dead lock. For the other cases, the adapter works as
expected. I don't know if your example is a particular case or a common one.
I use to do this way and I have never fall in a deadlock to the point that I
thought that a sharable lock was substituable by a exclusive lock. Evidently
I was completly wrong, we can not substitute in any semantic context. But it
works on a lot of situations.

This do not means that all the algorithms expecting a SharedLockable will
result on a deadlock with the adapter of a ExclusiveLockable mutex, very
often the choice of a SharedLockable or a ExclusiveLockable is a matter of

How to express that is another history. Maybe we need to state that the
parameter is a model of a SharedLocable or a shared_lockable_adapter of an
ExclusiveLockable. But this seams yet to specific, what if the function
works as expected for another adaptation of another concept. Been forced to
define two functions with the same algorithms (copy/paste+rename) that
differ only on the name of the functions called do not seams better. This is
pure theory, we are not talking of a particular function, but IMHO we need
to define the function working for model of the SharedLocable concept, and
add some textual semantic constraints.

shared_lockable_adapter<model of ExclusiveLockable> is a model of
SharedLocable that could or not satisfy the semantic constraints. It is up
to the developer to use it or not. I 'm sure that this is not the first time
we have something like this. Some thoughts?

If the requirements you are talking off are related to the semantics of the
operations, you are right, the current C++ concepts wouldn't be of any help,
concepts do not capture semantics. Which kind of more fine-grained concepts
are you referring?

> Certainly it would help if algorithms could work with both shared and
> non-shared mutexes without extra effort.

Note that all the algoritms that works today with exclusive mutexes, can be
refactored to use shared-locks instead of exclusive locks on the reading
blocks. All these algorithms will work with both shared and exclusive
mutexes without any extra effort.

> I'm not yet aware of much
> generic code that uses mutexes and lock concepts. No doubt we will
> learn more as that code appears.

You are right, there is not too much generic code that let the user the
synchronization context, most are not thread safe, and delegate this
responsability to the user. I supose that this kind of code will be more
frequent than we use to. We can see the work on lock-free algorithms and
containers. Thread safety starts to be a must as it was exception safety
some years ago.

The multi-core/multi-processor/grid architectures push the software to go in
this direction, parallelism, parallelism ... and even if this will be more
complex without the good abstractions and there will be a long way to get
them, the result will be more close to our thinking.

Sorry for my english and thanks for your pertinency


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