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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2005-04-30 08:01:29

Matt Hurd wrote:
>>Michael Glassford
>>
>>>Matt Hurd wrote:
>>
>>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), 
> 
> 
> Yep, promotion is generally poor practice in my book as you have to
> try hard if you don't want to deadlock or end up with a false economy.
>  Having a special mutex/lock that supports it is my preferred option
> for keeping it away from normal behaviour.  "It's over there  in the
> closet if you really insist..." ;-)
> 
> 
>>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).
> 
> 
> It still not clear to me how the lock transfers operate under
> simultaneous requests.

"Transfer" from a mutex is really just a delayed call to a lock method, 
so I don't see a problem: if there are simultaneous requests, one blocks 
and the other doesn't.

Transfer from a lock shouldn't happen simultaneously (locks, by design, 
are not thread-safe), so that shouldn't be a problem either.

> What does the transfer object buy you over:
> 
> That is,
> 
> why 
>     l = m.promote(l.transfer());
> 
>     l = m.promote(l);

In this case, the .transfer() isn't really necessary; if people prefer, 
it could be omitted. In the case of actually transfering from one lock 
to another, I think it's best require the .transfer() in order to make 
the transfer explicit.

> By the way I think the l is a bad name to use in examples as it is
> hard to see 1 l for I.  lk might be better short hand.
>

You're right; sorry.

> 
>>>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.
> 
> 
> Should locks really be transferable or should shared_ptr< lock > be
> the idiom if you want to go beyond scoping?
> 
> 
>>>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?
> 
> 
> 
> Yes.  It works just dandy as the precondition is weaker and the post
> condition is stronger.

OK. Just wanted to be sure I understood you.

> In a similar vein, shared and exclusive do nothing on the null mutex.
> Write to a shared model and get non-concurrent and exclusive model
> behaviour also.  This is only possible if you write to a shared model
> as there is no real way to write from a simpler model and have sharing
> introduced automagically.

I understand.

> As an aside, I guess writing to a promotable shareable model would
> like wise be substitutable back if the promotion always fails
> (shareable model) or always succeeds (exclusive model).
> 
> This gives you a substitutable taxonomy of
> null->exclusive->shareable->promotable.
> 
> Write the appropriate model and the "lesser" models work making
> architectural components much more flexible.
> 
> Similar thing to what ACE has been doing for over a decade...

Mike