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

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2005-04-28 22:58:42

> Howard Hinnant <hinnant_at_[hidden]> 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.

I disagree, which suggests perhaps it should be configurable to make
us both happy.
 
> 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.

I can see performance issues, but I fail to see a correctness issue. 
Do you have an example?

I can imagine a failure on code that requires concurrent shared access
from two or more threads, but I've never seen such code.

> 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) ).

I already extensively use such a generic capability with success.  I
find writing a component to a shareable model and being able to use it
with exclusive or null mutexes very useful and an advance over model
specific structures.

$0.02

Matt.

> -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

I'll have a look.  It is certainly impressive looking.  There is a lot
of capability I've never needed there...