Peter Dimov wrote:
I mostly agree with Bronek Kozicki.
Thank you :)
I disagree that
void * mutex() const;
is a better mutex() accessor. On the contrary, I'd argue that mutex() should return a non-const mutex_type. A const return doesn't make a lot of sense given that our mutexes have no const member functions; the private interface is a better protection than the const.
good point.
On the other hand, a non-const return allows the client to use scoped_lock<> on user-defined mutex types (in implementing the user-defined condition::wait, for example).
another good point. But then, I think that mutex() should be non-const in order to make it clear that owned mutex might be modified, and we should have another const member function just for one purpose - test if two locks are for the same mutex: template <typename Lock> bool same_mutex(const Lock&) const; or maybe just: bool same_mutex(const base_lock_class& ) const; or maybe (???) overloaded operator== Incidentally I think that function same_mutex could be considered as one of two (besides "bool locked() const;") publicly available members of base_lock_class. I'm not sure that it's good idea, but maybe it's worth consideration. Locks do not have to be polymorphic (as in OOP) in order to provide this functionality, but still it will bring some extra cost. B.