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

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-07-09 23:20:37

Hidey ho,

>On Fri, 9 Jul 2004 20:17:51 -0700 , Glen Knowles <gknowles_at_[hidden]> 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.