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.
> > 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?
> 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.
It looks like a documentation bug to me.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk