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

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-11-01 11:36:13

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.

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

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

> No it wouldn't. PODs can have member functions. You would have to wrap your
> pointer in a struct, but that wouldn't stop it being  POD. Yes, you wouldn't
> be able to use a plain 0 as an initializer, but you could use a static
> zero-initialized instance of the struct.

Hmm, might indeed be possible. I'll try this :-)

>> E.g. the current boost mutex also does not need to make these
>> explicit functions.
> 
> Which leads to the mess that is boost::detail::lock_ops, to enable code
> outside of the scoped_lock implementation (e.g. cond var implementation) to
> access these functions. People also use things like
> boost::shared_ptr<boost::mutex::scoped_lock> to get round the restrictions.

I don't think that this is the main reason why it was done this way (I
might be false.) This is just to express common behavior. It is easy 
enough to access the mutex objects inner semaphore/CRITICAL_SECTION from
the contained scoped_lock classes.

But thank you for your explanations, I'll try to do the aggregate mutex
with exposed locking and tell you my findings.

Roland