Re: [boost] Re: Lock unification [move]

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.