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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-11-01 11:51:06

Roland Schwarz <roland.schwarz_at_[hidden]> writes:

> Anthony Williams wrote:
>> I guess that by "locks" you mean scoped_lock. Howard has answered this before:
>> there are use cases where you don't want strict scoped locking, so yes, users
>> are "allowed" to access the lock member functions directly.
>
> No this isn't what I mean.
>
> mutex mx;
>      mx.lock();
>
> Why is this required, as well as:
>
> basic_lock lk(mx, defer_lock);
>      lk.lock();
>
> This is what I see as redundant.

They perform different duties. mx.lock() is a low-level interface. basic_lock
is higher level, and automatically unlocks in its destructor, if locked.

> Btw.: I never understood why one wanted direct locking of a mutex
> on Boost.Thread. You always have been able to say:
>
> boost::mutex mx;
> boost::scoped_lock lk(mx,false);
>
> void foo (boost::scoped_lock* pl) {
> 	pl->lock();
>
> 	pl->unlock();
> }
>
> 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.)

As you just said, scoped_lock isn't MT safe, so you can't use it to emulate
true public lock member functions on the mutex. 

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

It makes it harder than necessary.

> Also being able to lock directly on the mutex opens
> possibility to do such dangerous things as trying to lock/unlock
> from different threads.

Yes. That's why we must provide the scoped_lock stuff too. If we provide the
safe option, and make it easy to use, then most people will use it. If people
don't, and they get into difficulty, the first suggestion should be that they
use the easy and safe interface instead.

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

No it doesn't. A named mutex scheme doesn't need to store *any* information in
the mutex object, however the lock functions are accessed.

>> I don't think we need that freedom.
>
> So you don't think my POD mutex of value? Sorry I think I
> misunderstand you. You already said differently, didn't you?

Yes, you misunderstood. I think a POD mutex is of value.

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk