Boost logo

Boost :

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

> From: Howard Hinnant [mailto:hinnant_at_[hidden]]
> >>>> 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.


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