From: Howard Hinnant [mailto:hinnant@twcny.rr.com]
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 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.
If r/w locks regularly encourage deadlocks, I am not anxious to further pursue them. I'm not convinced of that however (and hope I won't be). I'm seeking a system which makes it easy to avoid deadlocks, race conditions, and leaked locks. Admittedly any system can be abused. But a good system will naturally reduce accidental abuse, while not necessarily preventing intentional abuse.
Holding multiple locks regularly encourages deadlocks, if you don't do that you'll be okay. ;) Anything else I think you have to be careful. That's a big part of why I'm not so worried, I think the vast majority of cases only require one lock at a time, beyond that you're probably trying to do something complex.
There's not overhead in the lock, but in the rw_mutex to support both read/write and upgradable_read. But hanging a try_promote on multiple upgradable read locks really makes me nervous. Doing so (imho) makes deadlock significantly more likely (see my post with lock_both/transfer_lock example).
Fwiw, here's what I'm seeing that is scaring me:
A holds ur. B holds r. A waits for B to unlock r so it can unlock ur and lock w. B waits for A to unlock ur so it can lock ur.
Yes, multiple readers all trying to upgrade. What made it interesting to me is that its one of the few cases where a deadlock detector gets to kill multiple waiters. AFAIK r/w locks only makes sense if you're going to hold read locks for a period of time, otherwise you're better off just using a regular mutex. Glen