[boost] Re: Lock unification

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 16:23:40

"Eric Niebler" <eric_at_[hidden]> writes:

> David Abrahams wrote:
>> "Eric Niebler" <eric_at_[hidden]> writes:
>> 
>>>I continue to believe that a better interface for a unified lock
>>>involves descriptively named helper functions:
>>>
>>>scoped_lock l1( m );                 // lock unconditionally
>>>scoped_lock l1 = defer_lock( m );    // don't lock
>>>scoped_lock l2 = try_lock( m );      // try lock
>>>scoped_lock l3 = timed_lock( m, t ); // timed lock
>>>
>>> It's just as clear as you could hope for, 
>> I'm not convinced it is.  It potentially puts information about the
>> kind of locking being done very far from the actual call that does
>> locking.  
>
>
> True, but the other design under consideration doesn't help with
> that. It requires two-step construction for some constructs which
> could result in code like:
>
>    scoped_lock l( m, false );
>    maybe_takes_the_lock_i_dont_know( l );

I don't know what you're referring to.  I don't see any two-step
construction going on there.  Links or examples, please?

>>>and it's extensible. I feel that the single lock c'tor with a bool
>>>arg is less readable and rather inflexible.
>> Inflexible how?
>> 
>
> User's can't add more constructors if they want a different locking
> strategy, but they can add as many helper function as they like. For
> instance, they could define a function that tried to take a timed_lock
> and logs failures. Or throws an exception. Or they could write a
> lock_if helper that takes a predicate. And they can do all that with
> simple one-step construction syntax. It's more concise and it permits
> the lock declaration to appear in the condition of if statements.

Sorry, I missed the "single lock ctor" part.  I think I agree with
you there.

BTW, it just occurred to me that

     timed_lock(m, 0)

could potentially generate different code from

     timed_lock(m, some_int)

If we can detect literal zero... which I think is possible.

What about:

  scoped_lock l(m);               // block
  scoped_lock l(m, 0);            // try
  scoped_lock l(m, 33);           // timed

  scoped_lock l(m, deferred);     // deferred 
  scoped_lock l(deferred(m));     // alternate
 
??

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com