Boost logo

Boost :

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

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?


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