When you hand a recursive mutex down from one routine to another, the callee cannot know the state of predicates in the caller. It has to assume there are some, because it cannot verify there aren’t; and if the caller had known that there were no broken predicates, it should have allowed concurrency by unlocking.

When you hand a recursive mutex down from one routine to another, the callee cannot know the state of predicates in the caller. It has to assume there are some, because it cannot verify there aren’t; and if the caller had known that there were no broken predicates, it should have allowed concurrency by unlocking.

So, late night hacking trying to fix a stupid bug in Spotify. Find out that all mutexes in the Spotify codebase are recursive. Googleathon about recursive locks. Find interesting stackoverflow answers and blog posts and stuff. Some say recursive locks are Evil, but their arguments aren’t super-solid. Find the guy who wrote recursive locks in pthreads. He has good arguments.

Basically: If you don’t know exactly the state of the stuff the lock is locking, how can you ever dare to call out to other code that would modify the stuff by taking the recursive lock? If you DO know exactly the state of the stuff the lock is locking, why are you holding the lock?! In other words, don’t use recursive locks.