Roland Schwarz <roland.schwarz@chello.at> 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