RE: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Glen Knowles (gknowles_at_[hidden])
Date: 2004-07-09 17:54:14

From: Howard Hinnant [mailto:hinnant_at_[hidden]] 
>On Jul 9, 2004, at 4:11 PM, Peter Dimov wrote:
>>> rw_mutex m;
>>>
>>> void invitation_for_deadlock()
>>> {
>>>      read_lock r(m);
>>>      // ok to read
>>>      upgradable_read_lock ur(m);
>>>      r.unlock();
>>>      write_lock w(ur);
>>>      // ok to write
>>> }
>>>
>>> It took me awhile to spot the deadlock in the above code.  Does 
>>> anyone else see the above code as scary?  (scary as in looks ok but
isn't).
>>> Or is the deadlock obvious to everyone else (and thus not scary)?
>>
>> Not scary, IMO, even if not obvious, because it always deadlocks, as 
>> soon as you attempt the "idiom". You can't miss it.
>
> I'm not following "always deadlocks".  If only one thread enters, at 
> what point does it deadlock (assuming no other thread playing with m)?
> Experimentally running through this on my prototype implementation 
> with a single thread isn't deadlocking.  But perhaps my prototype is
buggy?

It only deadlocks under a race, but I'm not sure it's scary. It's something
I'm use to seeing in the presents of r/w locks. 

I don't know where you left off, are you implementing single upgradeable or
multiple upgradeables? If only one upgradeable can exist in the system at a
time then, what would deadlock, will result in a failure to create a second
upgradable lock, IIUC.

You can always manufacture ways to deadlock, I'd still vote for just hanging
a try/timed_promote() on all read locks. Unless perhaps there's overhead in
upgradable_read_lock that isn't required in read_lock?

Glen