[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-06-29 10:08:08

Michael Glassford wrote:
> I would consider this more an argument for eliminating 1-argument
> constructors entirely (except for scoped_lock, where its meaning is 
> completely unambiguous):

It does appear that the design of the Scoped*Lock classes was very 
deliberate in having distinctly different constructor semantics. Though 
it's curious that all three have a L l(m,b) constructor so that

{
   LockType l(m, true);
}

will always have blocking semantics, regardless of lock type, and that

{
   LockType l(m, false);
}

will always create an unlocked lock. This being the case, it would be a 
convenient shorthand to add

{
   LockType l(m);
}

to all three Scoped*Lock concepts to support the generic case of a 
blocking lock. But it's just a shorthand, so it can be relegated to a 
wish list item.

> 
>> Refinements of a concept can only add restrictions,
>> they cannot remove them.
> 
> 
> True. But it's not hard to define the concepts in such a way that the
> lock classes can have different constructors:
> 
> Lock concept defines all lock operations except constructors.
> TryLock concept refines Lock by adding try_* methods.
> TimedLock concept refines TryLock by adding timed_* methods.
> 
> ScopedLock refines Lock by adding appropriate constructors.
> ScopedTryLock refines TryLock by adding appropriate constructors.
> ScopedTimedLock refines TimedLock by adding appropriate constructors.

This isn't necessary, because the Lock concept that all three currently 
refine from does not define any constructors.

Lock concept defines basic lock operations and destructor.
ScopedLock refines Lock by adding constructors.
ScopedTryLock refines Lock by adding constructors and the try_lock method().
ScopedTimedLock refines Lock by adding constructors and the timed_lock 
method().

But it looks as if the original concepts are not as generic as I may 
have hoped, at least on construction. Perhaps this is the right answer, 
as locks are (according to the docs) supposed to be shorted lived objects.

-- 
Christopher Currie <codemonkey_at_[hidden]>