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

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2005-04-28 21:12:07

> 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.
What does the transfer object buy you over:

That is,

why 
    l = m.promote(l.transfer());

    l = m.promote(l);

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.
 
> > 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.

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.

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...

Regards,

Matt.