David Butenhof explains, in 2005 in comp.programming.threads, why POSIX has recursive mutexes: “Because of a dare.”
He also writes:
First, implementation of efficient and reliable threaded code revolves around one simple and basic principle: follow your design. That implies, of course, that you have a design, and that you understand it.
A correct and well understood design does not require recursive mutexes.
Fiery Robot writes, in 2008, Recursive Locks Will Kill You!:
Better to use a real honest-to-goodness lock. This means that if a thread tries to lock a lock that’s already, well, locked, you’ll deadlock. This is good. I like this, just as I like crashes. I know, you think I’m crazy, but if you deadlock on your own thread, then you know you just did something bad.
Google Mac Blog writes, in 2006, in @synchronized swimming:
Shark told us without a doubt that we were paying heavily for the @synchronized block each of the millions of times we were calling fooFerBar… So, I wondered, how exactly does @synchronized work? And is there a cheaper way of getting the same thread-safe result?
(For new Cocoa developers: Shark was the performance profiler we used before performance profiling was added to Instruments.)
Which Locking System I Use
I haven’t used @synchronized in years. Not only is it recursive (which I tend to avoid), it sets up an exception handler. I would way rather have my exceptions go unhandled. (I don’t know if it’s still slow compared to other locking systems, but I strongly suspect it is.)
So there are two that I use:
OSSpinLock. It’s great when contention is expected to be low. (Which is surprisingly often.) It’s super easy to use.
Pthread mutexes. You can create these as recursive locks, though I try to avoid it.
(There’s one recursive lock in Vesper, and I’m switching it to non-recursive — to OSSpinLock — today.)
Better, though, is to design so as not to need locks. Good use of GCD serial queues, blocks, and the main thread can often make locks unnecessary.