Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-23 07:06:05

Howard Hinnant wrote:
> On Jul 22, 2004, at 1:16 PM, Eric Niebler wrote:
>> Please no. The scoped_lock keeps track of whether it has locked the
>> mutext or not, so it kows whether or not to unlock the mutex in its
>> destructor. If you make the mutex interface public AND expose the
>> mutex of the lock, you break encapsulation:
>> mutext m;
>> {
>> scoped_lock l( m ); // locked
>> l.mutext()->unlock(); // unlocked
>> } // unlocked again by l's destructor!
> I just knew I was getting too much in the mood of: Here's the rope,
> don't hang yourself! :-)
>> It is for precisely this reason that I think you shouldn't be able to
>> get a pointer to the mutex from the scoped_lock. You should get back
>> a token or a void* that is useful only for comparison purposes.
> I'll let you and Peter hammer that one out. I could be happy with
> whatever you guys decide.

The point is that the scoped_lock<> template does not make any decisions or
assumptions about the accessibility of the mutex interface.

That is, even if scoped_lock<> (the usual suspect - parameter defaults to
'mutex') gives you a mutex*, you still can do nothing with it (unless you a
a frind of said 'mutex' class, i.e. you are a condition variable ;-) ).

However, when scoped_lock<MyMutexType> returns you a MyMutexType*, you may
be able to do something with it.

IOW: the decision as to whether to expose the mutex interface to the general
public is made by the designer of the mutex class. The lock class is a
fully-specified, general purpose helper. Its interface is not influenced by
the standard mutex types.

Boost list run by bdawes at, gregod at, cpdaniel at, john at