Re: [boost] [thread] Question about MT API C++0X N2094

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 
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