Solaris introduced turnstiles to reduce mutex overhead and prevent priority inversion in blocking locks

Solaris engineers found that traditional blocking mutexes required a significant amount of metadata to track ownership, waiting threads, and the state needed for blocking and waking. This metadata made each lock expensive, which conflicted with the goal of fine-grained locking where many locks protect small pieces of state. At the same time, blocking locks did not disable preemption, opening the door to priority inversion when a low-priority thread held a lock needed by a high-priority thread. Turnstiles were introduced to solve both the size and the inversion problems.

A turnstile is a separate kernel object that holds the lock’s owner, the list of threads waiting for it, and the coordination state needed to block and wake those threads. The mutex itself is reduced to a small flag or pointer that references the turnstile, so adding another lock costs only a few bytes. When a thread blocks on a mutex, it is attached to the corresponding turnstile; if another thread with higher priority later blocks on the same mutex, the turnstile can raise the priority of the owner thread. By chaining turnstiles together, the system can propagate a priority boost through multiple nested locks, achieving multi-hop priority inheritance.

Because the mutex is now tiny, developers can afford to use many more locks, enabling finer granularity without paying a large memory penalty. This reduces contention and improves latency for high-priority tasks, giving Solaris the soft real-time behavior it aimed for. The idea proved useful beyond Solaris; variations of turnstiles appear in other UNIX-derived kernels, in web browsers’ scheduling subsystems, and in language runtimes that need efficient locking primitives. Thus engineers working on modern systems may encounter turnstile-based locking even when they never see Solaris code directly.

The turnstile approach adds indirection and requires the kernel to manage an extra data structure for each lock, which introduces a small amount of overhead and complexity. If lock chains become very deep, traversing the turnstile list to propagate priority can take longer, potentially limiting scalability in extreme cases. Moreover, the benefits depend on correct implementation of priority inheritance; if a system omits or misconfigures the turnstile mechanism, the priority inversion problem can reappear despite the mutex remaining small. Therefore, while turnstiles solve the original problems, they trade a bit of kernel complexity for the gains in lock size and priority safety.