From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-15 14:11:44
Eric Niebler wrote:
> Peter Dimov wrote:
>> The "unified" timed lock case is
>> scoped_lock l( m, false );
>> if( l.timed_lock( t ) )
>> // do stuff
>> // what do we do here? presumably either:
>> // setup for unbounded wait
>> // 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
> Earlier I posted code demonstrating how this interface could be made to
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk