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@gmail.com>