[boost] Re: Lock unification

From: Eric Niebler (eric_at_[hidden])
Date: 2004-07-15 15:24:33

Michael Glassford wrote:

> Eric Niebler wrote:
>>
>> 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.
> 

This is true, but once we add a scoped_lock constructor that takes a 
bool, we can't take it back out. If we then added helper functions, we'd 
be giving people two ways to do the same thing. Not a big deal I 
suppose, but I'm a minimalist and would prefer only one way.

> In your opinion, should a unified lock then have no locking 
> constructors, or should it have only the one already proposed?
> 

My opinion? Hmm ... I'd like to see scoped_lock have one public c'tor 
that took a mutex and locked unconditionally. That's the most common 
case, so it should be simple and concise. Everything else would be an 
appropriately named helper function.

My $0.000002.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com