in reply to Recursive locks:killer application. Do they have one?
I have never found it necessary to use such a mechanism either. Also, I think that such niceities, well-intentioned though they might be, might actually tend to create less-debuggable code simply because they are more permissive than they strictly “need” to be. One of my mentors referred to it as (and I always loved this expression...) “Coding for WTF?!?!” The notion being that, the more things that are allowed to occur, the more possibilities to have to sift through when you are faced with an evident bug but don’t yet know where. Multiprocess code is already notoriously hard to debug, without “help” from the OS. :-)
It is appealing, maybe, to somehow pawn “doing the right thing” off to the operating system ... but “a general case” is hard to consider here, which means that the OS code starts filling up with decision heuristics, which might match your case or simply be an unwanted degree-of-freedom in the mechanism that you are constructing. If you need a mechanism like this one, you can construct it using simple atomic primitives. (And if you do, you’d probably want to have an “already locked by this process” error-code from the OS primitive.)