Eric Niebler wrote:
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:
I like it better too, but...
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.
I believe there was (nearly?) consensus that we want to make locks movable at some point. My conclusion was that at that point this syntax becomes possible, too. I think Peter said or implied much the same thing, maybe before I did. As I mentioned in another recent reply, the unified lock won't be in the upcoming release; making locks movable may happen before the next release after that, making this syntax possible in that release also. In your opinion, should a unified lock then have no locking constructors, or should it have only the one already proposed? Mike