Peter Dimov wrote:
The "unified" timed lock case is
{ scoped_lock l( m, false );
if( l.timed_lock( t ) ) { // do stuff } else { // what do we do here? presumably either:
// setup for unbounded wait l.lock(); // do stuff
// or signal failure } }
The scoped_timed_lock use case also needs to eventually contain an if( l ) statement; you can't do much if you don't know whether your timed lock succeeded. One might also argue that a separate scoped_timed_lock makes accidentally omitting the if() statement more likely and harder to spot.
But it's hard to tell without real use cases.
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, and it's extensible. I feel that the single lock c'tor with a bool arg is less readable and rather inflexible. Earlier I posted code demonstrating how this interface could be made to work. -- Eric Niebler Boost Consulting www.boost-consulting.com