[boost] Re: [threads] Improvement idea #1: Lock constructors [long]

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2005-04-30 07:48:15

Howard Hinnant wrote:
> On Apr 28, 2005, at 9:31 PM, Michael Glassford wrote:
> 
>> What happens when you request a shared lock from a non-shared mutex?  
>> It just gives you an exclusive lock?
> 
> 
> Imho, a compile time error.
> 
> A mutex has certain capabilities.  Some mutexes may support shared  
> access, some not.  If a shared lock tries to "lock" a mutex, that means  
> that it is trying to tell the mutex to "lock_sharable".  If the mutex  
> doesn't support that function, it should complain and loudly.
> 
> Failure to do so may cause generic code to compile and cause silent  
> (and subtle) run time errors.  The generic code may be expecting shared  
> locking, and may even work correctly if mistakenly given an exclusive  
> lock, but perform orders of magnitude slower.  When the performance hit  
> is this big, a compile time error is preferable.  (e.g. this is the  
> only reason we don't give std::list an operator[](size_t) ).
> 
> -Howard
> 
> PS:  Here is my wishlist of mutex capabilities.  But this list isn't  
> meant to imply that all mutexes must support all of these capabilities.  
>  Locks should be able to pick and choose what they need out of a mutex,  
> using only a subset of this functionality when appropriate.  A lock  
> templated on a mutex will only require those mutex capabilities  
> actually instantiated by the lock client.

This is exactly what the design I suggested is intended to accomplish, 
except that the lock class no longer needs to be templated on the mutex 
because the locking interface is actually in the mutex, not in the lock 
class at all. A single, non-templated lock class works with any mutex. 
In effect, a lock becomes a specialized ScopeGuard: all it needs to know 
is whether it is locked and what function to call to unlock.

Mike