Doug Gregor wrote:
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.
I'm not sure exactly what you're suggesting here. Are you talking about only the constructors, or would you completely eliminate all blocking functionality (e.g. the lock() method) from try_lock? And all non-timed functionality (e.g. the lock() and try_lock() methods) from timed_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.
There's a lot to be said for separate read-lock and write-lock types, and I was hoping to address that at some point; however, it would make lock promotion/demotion more difficult (unless maybe the read_lock class had a promote() method that returned a write_lock class or something like that, but that has some problems, too).
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost