Boost logo

Boost :

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2005-04-28 20:31:03

Matt Hurd wrote:

[snip other stuff]

>>#2: instead of the following, which in my mind leaves an ambiguity of
>>whether the mutex should be unlocked, shared-locked, or exclusive-locked
>>at the end:
>> shared_lock l1(shared_mutex, SHARED_LOCK);
>> ...
>> {
>> exclusive_lock l2 = l1.promote();
>> ...
>> }
>>It is possible to write this, which removes the ambiguity:
>> lock l = shared_mutex.shared_lock();
>> ...
>> l = shared_mutex.promote(l.transfer());
>> ...
> Bad example I think. Personally, the risk of dead lock from trying to
> promote shared to an exclusive lock strikes me as goto-esque. I
> really struggle to find a compelling use case that makes the danger
> involved worthwhile. I recall suggesting that if the dangerous
> efficiency was really required it should be through a special
> promotable shareable mutex rather than the normal shareable one.

If I read this correctly, it's an objection to the idea of promotion in
general (except for the special case of a promoteable shared lock), in
which case I tend to agree; however, I want to specify the syntax that
promotion would use even if the Boost.Threads shared_mutex ends up not
using it, because I want to allow custom shared_mutex classes that do
use it to be used with Boost.Threads lock classes (better support for
custom classes being used with Boost.Threads classes is something I plan
to cover in a later posting).

> I agree with your push to clean up the lock constructor interface. I
> currently wrap them all and use my own interface so I can have generic
> code for null, exclusive and shared ops.
> Not sure about the lock transfer object as it is really just another
> name for a lock. After all it is the token representing the locked
> state, or a lock by another name... Perhaps just being able to return
> a lock from a mutex and being able to transfer ownership by copying a
> lock like an auto ptr would give you the same thing. I need to think
> about this some more.

Except that lock objects can only be transferred explicitly by calling
their transfer() method and have public constructors, while
lock_transfer objects transfer implicitly and can only be constructed by
mutex and lock objects. You can't tell this from what I posted, however.

> Importantly, I believe you need to be able to request a share lock
> even of an exclusive mutex or null mutex so that you can write generic
> concurrent code. You write to a shared model and the other models
> work.

I was intending to have better support for generic code, though I
planned to cover that in a later posting.

What happens when you request a shared lock from a non-shared mutex? It
just gives you an exclusive lock?

[snip code]


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