From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-11-01 12:03:31
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk