Howard Hinnant <hinnant@twcny.rr.com> 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...