[boost] Re: [threads] Improvement idea #1: Lock constructors [long]

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());
>>    ...
>>
>>Comments?
>>
>>Mike
>>
> 
> 
> 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]

Mike