Boost logo

Boost :

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.



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

Boost list run by bdawes at, gregod at, cpdaniel at, john at