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) ).
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk