RE: [boost] Re: recursive mutex and condition

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-09-16 09:05:40

James Ahlborn <james.ahlborn_at_[hidden]> wrote:
> > 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.

Yes, I understand all this.

<snip> 
> > 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,

"Minimal knowledge"?  Does that mean you think he's wrong in fact, or
that his opinion about its usefulness is mistaken?

> 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.

As I understand it, your reason for using a recursive mutex would be
that there are functions that require a weaker invariant and may
safely be called from a function that holds the mutex and has broken
the normal invariant, but may also be called without the mutex being
held.  (If a function requires the normal invariant then you need
to re-establish that before calling it, and having done so you could
safely unlock the mutex, removing the need for it to be recursive.)

This means that responsibility for re-establishing the normal
invariant for a recursive mutex is divided up between several
functions.  So how can the single function that waits on the
condition re-establish the invariant?  Wouldn't that require a gross
breach of the modularity you want?

<snip> 
> 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).

I do.

> yet, they don't work, and I'm wondering if that is intended or a
> bug in boost.

It looks like a documentation bug to me.