Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at