Roland Schwarz wrote:
if you needed that behavior and doing away with the scoped feature. (Of course you need to take care not to do this from different threads since scoped_lock isn't MT safe.) It just isn't so obvious, which is a good thing, since scoped locking is far more safe. But it never prevented you from such practice. Also being able to lock directly on the mutex opens possibility to do such dangerous things as trying to lock/unlock from different threads.
Requiring the ability to lock directly on the mutex object forces the implementation to be able to hold the entire state in the mutex object.
I don't think we need that freedom.
I think the main reason for the approach of direct locking is the need to establish a simple scoped locking framework independently from the mutex implementation. Currently in Boost.Thread the mutex must somehow give access to scoped lock to use the locking functions (friend or whatever). N2094 wants to design a locking framework just like the STL algorithms. Mutexes would be like containers, with public interfaces and well known semantics. Scoped locks would be the equivalent to STL algorithms. Algorithms and Containers don't know about each other, but any Container that has the necessary public members can be used with an STL algorithm. This approach allows the user to construct more locking utilities and synchronization utilities easily. I don't know if this was the answer you were finding, is it? Regards, Ion