Boost logo

Boost :

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

> > I think you should avoid using recursive mutexes. Read
> > <>.
> 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?

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at