From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-11-01 12:21:26
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk