|
Threads-Devel : |
From: Anthony Williams (anthony_at_[hidden])
Date: 2007-12-06 11:14:40
Quoting Frank Mori Hess <fmhess_at_[hidden]>:
> On Thursday 06 December 2007 03:02, Anthony Williams wrote:
>> Quoting Frank Mori Hess <frank.hess_at_[hidden]>:
>> > Is it possible to make condition_variable_any work with recursive
>> > mutexes? It
>> > seems like an additional interface on the lock would be required,
>> > since a recursive mutex may still be locked by the current thread even
>> > after calling unlock().
>>
>> I think that would be dangerous. If you don't know how many times
>> you've locked the recursive mutex when you call wait() (in order to
>> unlock all but one prior to the call), then you might be unlocking the
>> mutex when a layer above you is expecting it to still be locked and
>> has incomplete changes that are protected by the lock.
>
> Okay, I suggest a sentence be added to the condition docs to explicitly
> state it is unsafe (will probably deadlock) to wait on a recursively
> locked mutex.
That's a good idea.
> I wonder if a sanity check could be added to condition::wait() to test for
> this case. It would require a generalization of owns_lock(), which
> instead of returning a bool, returns an integer indicating how many times
> the current thread has recursively locked the mutex. Then wait() could
> check it returns exactly 1.
That's something worth bearing in mind. There's nothing to stop
condition::wait being specialized for a lock on a recursive mutex to
do that.
Anthony
-- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL