1) You don't know the mutex is being used recursively. In this case, the
recursive mutex will hide a serious problem.

    2) You know the mutex is being recursively. In this case, just don't
lock it since you know it's already locked anyway.

    The problem is that recursive mutexes hide something from you and that
something is extremely important. Consider code like this:

A) Lock mutex
B) Unlock mutex
C) Do something, assuming the mutex is unlocked

    What happens if the mutex is recursive?

    The only value of a recursive mutex is that it allows you to write a
function that works properly whether or not a mutex is locked. But the
caller must know that the mutex is locked anyway, so why not just have two
versions of the function? (With the one you call without a lock possibly
just being a wrapper that grabs the lock and calls the other function.)

    It's just too hard and dangerous to write sensible code that works with
a mutex that might or might not start out with that mutex locked and with no
way to tell which. And the only value of recursive mutexes is that they let
you do this.

    DS