Solaris turnstile's bucketed hash design prefigured Go sematable and WebKit WTF::ParkingLot

Solaris depended on blocking mutexes for soft real-time behavior, which created two problems that grew with concurrency. Fine-grained locking produced thousands of locks each carrying heavy bookkeeping, bloating memory, and priority inversion could stall high-priority tasks behind preempted low-priority holders. Turnstiles fixed both at once by moving wait state out of the lock and into a separate per-thread object that gets donated to the lock on contention. A global, bucketed hash table keyed by the lock's virtual address maps threads to the right queue, which keeps uncontended locks down to roughly a single byte or word while still enabling priority inheritance traversal.

Go's runtime faces the same scaling pressure with goroutines rather than kernel threads, and adopted the same decoupled shape inside sema.go. The runtime maintains a global table called semtable, organized into semaRoot buckets. When a goroutine blocks on a mutex, channel, or other synchronization point, its address is hashed to locate a semaRoot, and the goroutine attaches itself to a treap of sudog structures tied to that bucket. The result is that individual synchronization variables stay extremely lightweight, while the cost of contention is amortized through the shared semaRoot layer rather than paid by every primitive.

Browser engines hit a comparable constraint, since they juggle many threads and cannot afford to bloat every lock. WebKit answered this with WTF::ParkingLot, a portable user-level parking mechanism that mirrors the Solaris design. Standard locks such as WTF::Lock are shrunk to a tiny footprint and no longer carry OS mutex or condition variable state directly; when a thread must block, it parks itself by registering with ParkingLot rather than embedding wait queues in the lock. The same externalization of wait state shows up again, with the same trade-offs.

The shared cost of the pattern is a deliberate engineering trade-off: minimal per-lock footprint in exchange for global hash bucket lookups and bus traffic when contention is high. Under sustained heavy contention, throughput can bottleneck on the hash bucket lock itself, not on the lock the threads are fighting over. The design also assumes priority inheritance chains can be tracked efficiently, which is notoriously hard once dependency graphs grow. For systems that do not need soft real-time guarantees or millions of contended threads, the simpler embed-wait-queues-in-the-lock design still wins; at the scale Go and a browser engine operate, the bucketed approach becomes the cheaper option precisely because lock-object bloat becomes the dominant cost.