From: Howard Hinnant [mailto:hinnant@twcny.rr.com]
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