[boost] Re: recursive mutex and condition

From: James Ahlborn (james.ahlborn_at_[hidden])
Date: 2004-09-15 14:56:25

> Ben Hutchings <ben.hutchings <at> businesswebsoftware.com> writes:

> I don't believe so.  If waiting for a condition releases the mutex
> only once, this can result in deadlock, and if it releases the mutex
> completely the protected data can be seen while its invariant is
> broken.  There seems to be no right way to use recursive mutexes with
> condition variables.

umm, using a condition fundamentally implies releasing a mutex and then
reacquiring it.  regardless of the mutex type, one needs to make sure that the
invariants are valid when the mutex is released.  recursive mutexes are no more
than a counter combined with a mutex which means, if count > 0, i don't need to
call lock again; when count == 0, call unlock.

> 
> <snip>
> > I'm testing this on red hat 7.3 and fedora core 2.  My guess as to
> > why it's broken is because the boost condition uses posix recursive 
> > mutexes
> 
> There's no such thing.

my mistake, it is not a posix standard.  what i meant was the "recursive mutex
pthread extension type" in linux. 

> I think you should avoid using recursive mutexes.  Read
> <http://groups.google.com/groups?selm=3434E6BA.ABD%40zko.dec.com>.

well, i've programmed significantly in both java and c++ and i think the poster
of that comment is mistaken on many fronts.  besides the obvious bias against
java and the seemingly minimal knowledge of how "synchronized" works in java, i
think the fundamental argument of a recursive mutex being the "lazy man's mutex"
is wrong.  In any moderately complex system, trying to avoid using recursive
mutexes adds complexity to the overall design and eventually breaks the
modularity of the system.  Any coordinated use of modular classes with
non-recursive mutexes requires *even more* distributed knowldege of who holds
which locks than is already needed to avoid deadlock when using recursive
mutexes. I say this from experience.  I tried to implement things without
recursive mutexes, but the overhead tends to become ridiculous to impossible as
system complexity progresses.

to return to boost specifically, the implementation of recursive_mutex and
condition seem to imply their combined use.  I see no documentation which says
"hey, you should only use condition with a normal mutex", nor any compiler error
when i try to do so.  i see no "fundamental" reason why a recursive mutex and a
condition should not work together (they are quite happy in java).  yet, they
don't work, and I'm wondering if that is intended or a bug in boost.

thanks,
-james