On Tuesday 29 June 2004 9:15 am, Michael Glassford wrote:
Doug Gregor wrote:
but the point is that all locks should have the same behavior in the 1-argument constructor case, and that is to block until this lock is obtained. The is the only way the user can use the lock in a generic way.
Absolutely. This is *extremely* important to keep in mind when discussing any kind of concept taxonomy.
I would consider this more an argument for eliminating 1-argument constructors entirely (except for scoped_lock, where its meaning is completely unambiguous): there doesn't seem to be a way to define them that is both consistent within the lock class and consistent across lock classes (e.g. I agree with Vladimir that for consistency within the try_lock class, it should be non-blocking; but as Christopher pointed out, for consistency across lock classes, it should be blocking).
Right, so what we have (I think) are reasonably well-designed classes with incorrectly specified concepts. scoped_lock should really lock; try_lock should just try to lock.
And, if you consider the larger case, which also includes read/write locks, single-argument constructors are even harder to define (do the read-lock or write-lock?; do they block or not?).
I'd expect scoped_*_read_lock and scoped_*_write_lock classes to be separate classes that model whatever locking concepts we come up with. Actually, the design of the read/write lock on the branch really surprised me, because it used the read_write_lock_state enum instead of distinct types.
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.
Looks perfectly reasonable to me. Doug