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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk