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