But this type of concern mostly only pops up when doing the style of threading + locking that Java pretty much encourages ...

Pre-1.5 Java is certainly the poster bot for recursive locks -- synchronized blocks -- which also makes it the poster bot for all that is wrong with them.

Hence the 1.5 moves to add finer grained locks. Though I think they went too far the other way with the need to explicitly unlock.

I like perl's current mechanism -- locking data rather than code blocks -- combined with it's semantics -- automatic unlocking at the end of the encompassing block. What I dislike is the overhead of current implementation with its need to count and no timeout.

Then, if you already are holding the mutex, you need to call doFooUnlocked(). But, that solution requires the bifurcation of all methods that might call doFoo*() which can lead to quite a mess.... I wish I had a much more concrete example handy.

Ditto the last part. Whilst appreciating that your example is abstract, it doesn't sound right to me.

IME, the whole idea of needing to retain a lock long enough to call out to another method just seems wrong to me. If what you need to do with the thing you are protecting is sufficiently complex to warrant calling a subroutine to do it, then your design strategy is all wrong. Like declaring variables, locks should be taken as late a possible and in as small a scope as possible. And that means they should not be held across function/method call boundaries.

I'm still open to the idea that there exist algorithms that require recursive locks, but until I find a concrete example that I can't re-write to not use them -- without having to jump through hoops to do so -- I'm pretty settled on the notion that they should only be used as a last resort rather than a first.

For the most part, I think most of the bad press surrounding locking comes simply from bad programming. And most of that comes down to the belt & braces conservatism of applying locks to everything; too often; and fundamentally, for too long.

There is also a lot of bad academic research floating around. So called 'classical concurrency problems'. Things like this. There are reams and reams of academic treatise attempting to come with provably correct algorithms to deal with this, but not one of them suggests the obvious solutions. Buy five more forks. Or, eat with their fingers.

By far the easiest way of avoiding locking problems, is to avoid locking. Not always possible, but (I'm pretty sure) it is always possible to confine locking to very short pieces of code in very small scopes.

But the proof will be in the counter example.