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
>> }
>> 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