Ion Gaztañaga wrote:
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?
Yes I understand, but this framework forces the mutex object to contain state. Please don't get me wrong I know that a mutex needs to hold some state, but not necessarily the mutex object itself. A mutex has two aspects ID and state. I believe you can store state elsewhere but you can't forgo ID. Roland