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
> 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.
I'll have a look. It is certainly impressive looking. There is a lot
of capability I've never needed there...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk