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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk