Boost logo

Boost :

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..." ;-)
>>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
>>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...


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