James Ahlborn <james.ahlborn@med.ge.com> 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.