RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
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
Hidey ho,
On Fri, 9 Jul 2004 20:17:51 -0700 , Glen Knowles <gknowles@centor.com> wrote: 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.
Holding multiple locks is pretty common and necessary. If you can guarantee they will always be acquired in the same order they will not deadlock. There was some thought many moons ago in a boost thread about boost thread having a collection or other mechanism for guaranteeing the same ordering of access to mutexes to prevent deadlock. Not sure if this is a good idea as often the ordering is dictated by structure. Would be a nice thing when you need it though. Using non-recursive locking is the next biggest problem w.r.t. deadlock I find. Not so much of an issue on win32 as the basic critical sections are recursive. Not the case of POSIX. My next biggest deadlock frenzy comes from having objects in collections share mutexes, e.g. by a vector of them, to spare system resources. Sometimes I get myself in to trouble with dependencies between these when I haven't had the appropriate dose of caffeine. <snip>
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.
Concurrency may be better with shared access. The most common case for me is for collections. Multi-read might be quite important to your application's concurrent performance. Just another $AUD 0.02, Matt Hurd.
participants (2)
-
Glen Knowles -
Matt Hurd