[boost] Re: Lock unification

From: Eric Niebler (eric_at_[hidden])
Date: 2004-07-15 15:15:53

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

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

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com