My question was more about the design rather than how I could work it around. I may be wrong but specializing mutex does not look like a good idea as it appears to be lock-specific functionality. So, I thought we might consider having only mutex and typedefing others to it (not to break old code) -- the simpler the better. Isn't it? V.
Do we need all three separate concepts -- mutex, try_mutex and timed_mutex?
I think the idea was that it would be possible to implement the mutex types that supported fewer operations more efficiently. Whether this actually turned out to be true is another question.
I'd expect the mutex concept to remain unchanged and "try" and "timed" refinements to be related solely to the ways I try locking that only mutex. That is, I always have one mutex and under different circumstances lock it unconditionally (scoped_lock) or try locking it and check if that attempt succeeds (scoped_try_lock) or try locking within a certain time period (scoped_timed_lock).
If you want this, just use a timed_mutex and scoped_timed_lock. In the current release it supports lock() and timed_lock() operations; in the next release it will support try_lock() as well. Mike ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 772, Issue 2 *************************************