On Tuesday 29 June 2004 10:55 am, Michael Glassford wrote:
Doug Gregor wrote:
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?
I see that my comment was horribly ambiguous :) Let's try to forget I said it, and I'll pipe in elsewhere more clearly with suggestions.
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).
Could write_lock have a constructor/method that takes in the read lock to be promoted? I'm a little fuzzy on the implementation issues here. Doug