Boost logo

Boost :

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

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