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.