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

From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-07-15 12:48:35

Michael Glassford wrote:

> Actually, it has been suggested to eliminate the latter constructor that 
> takes a time as a parameter. There would only be one constructor:
> 
>    scoped_lock(Mutex m&, bool initially_locked=true);
> 
> which performs a blocking lock. Under this scheme, you would have to write:
> 
>    scoped_lock l(m, false);
>    l.timed_lock(t);
> 

I personally think this makes the interface more complicated, but I 
guess that's a matter of opinion. I liken 'lock-on-construction' to 
'resource-acquisition-is-initialization', but I can see how a timed-lock 
may not precicely model this concept.

> The main motivation behind the idea of unifying the lock types (and 
> mutex types) is simplification of concepts, I believe.

What concerns me is that it feels like the concepts are being loosened. 
By combining the lock concepts, you effective remove the ability to 
demand that a lock always be blocking, regardless of the type of mutex. 
I no longer have the option of saying:

template <typename mutex_type>
foo( mutex_type & m )
{
   mutex_type::scoped_lock l( m );

   // do work

   l.unlock();

   // do more

   l.try_lock(); // compile time error?

   // still more
}

If the locks are combined, whether this is an error is dependent on if 
the mutex supports a try_lock operation, whereas with the existing 
interface, this is always an error, because I've said up front that I 
only ever want to perform blocking locks here.

I'll also point out that the existing interface supports the opposite 
desire, a compile time error based on mutex_type:

template <typename mutex_type>
foo( mutex_type & m )
{
   // compile time error possible
   mutex_type::scoped_try_lock l( m );

   // do work

   l.unlock();

   // do more

   l.try_lock(); // ok

   // still more
}

This will compile if a TryMutex is passed, but not a plain Mutex, 
because scoped_try_lock is not defined for that type.

In the end, I feel that by combining the interfaces, we take away the 
ability of the user to be explicit and restrictive in her use of lock 
types. My other motivation is an "if it ain't broke, don't fix it" 
attitude; Unless it can be demonstrated that a change in the interface 
is necessary to support needed use cases, we may as well leave well 
enough alone (and devote time to adding new features :-)).

-- 
Christopher Currie <codemonkey_at_[hidden]>