So, would anyone care to summarize their take on what conclusions have been reached? I'm afraid I haven't had time in the last few days to respond much, or even to analyze everything as much as I would have liked; and in many cases, it's not obvious what conclusions were reached, if any. As far as I remember, the following topics have come up; undoubtedly I've missed something, so please add it to the list. Lock unification ---------------- Should the three lock types (lock, try lock, timed lock) be combined into one? Conclusion: the lock class should be implemented as a single class templated on the mutex type; trying to use operations that the mutex doesn't support results in a compile error. Question: does this mean unification of the lock concepts, too? Extended lock interface ----------------------- The lock interface should be extended to make it possible to determine if it is locking a particular mutex. How? Suggestions: Mutex& mutex() Mutex* mutex() void* mutex() mutex_id_type mutex() Conclusion: ??? Mutex/lock interface specification ---------------------------------- The private mutex interface used by locks should be specified so that others can write custom mutex classes that work with the Boost.Threads lock class. Mutex unification ----------------- Should the three mutex types (mutex, try mutex, timed mutex) be combined into one? Conclusion: I think it was concluded that a separate timed mutex is necessary. Possibly that the mutex and try mutex should be combined. That this combined mutex should optionally provide timed operations if they can be supported efficiently by the underlying platform. Read/Write lock demotion ------------------------ What should the lock demotion syntax look like? Conclusion: ??? Read/Write lock promotion ------------------------- Should lock promotion be supported or is it too problematic? Should there be failable promotion, promotion that uses upgradeable locks and doesn't fail, or both? What should the promotion syntax look like? Conclusion: ??? Other miscellaneous topics -------------------------- * The Boost.Threads implementation of a condition variable waiting on a recursive mutex that is locked more than once is buggy. * The very idea of a condition variable waiting on a recursive mutex that is locked more than once is a bad idea. Topics that were postponed -------------------------- * Making locks movable * Supporting "if (Lock l = ...)" syntax * Dealing with how time is specified in timed lock operations. Mike