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

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.

Glen