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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2005-04-28 21:28:41

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.

http://home.twcny.rr.com/hinnant/cpp_extensions/ 
threads_move.html#Summary%20of%20mutex%20operations