雖然 Sun Microsystems 的 Solaris 作業系統在現代市場已逐漸淡出，但其在系統工程上的技術遺產依然深刻影響著當前的軟體架構。從記憶體管理的 Slab Allocator、儲存革命的 OpenZFS，到動態追蹤框架 DTrace（Linux eBPF 的靈感來源）以及早期的虛擬化技術 Zones，Solaris 奠定了許多高效能系統的基礎。其中，一個名為 Turnstile 的同步機制，其核心設計理念至今仍被廣泛應用於現代網頁瀏覽器引擎與程式語言的運行時（Runtime）中。
同步機制的挑戰與優先級反轉
在開發低延遲或軟實時系統時，開發者通常會使用互斥鎖（Mutex）來確保執行緒同步。然而，當系統需要大量細粒度的鎖定（Fine-grained locking）時，會面臨兩個嚴重的工程挑戰。首先是記憶體開銷問題：如果每個鎖都必須內建複雜的等待佇列或管理數據，當系統中存在數以萬計的小鎖時，會浪費大量的記憶體空間。
其次是優先級反轉（Priority Inversion）問題。這發生在一個高優先級任務被一個持有鎖的低優先級任務阻塞時，而該低優先級任務又被中優先級任務搶佔（Preempt），導致高優先級任務無限期地等待，嚴重影響系統反應速度。為了修復此問題，核心通常採用優先級繼承（Priority Inheritance），即暫時提升鎖持有者的優先級。但若要高效地追蹤複雜的依賴鏈，會進一步增加鎖結構的複雜度與記憶體佔用。
Solaris Turnstile 的核心運作方式
為了在不增加鎖體積的前提下解決上述問題，Solaris 引入了 Turnstile 機制。其核心理念是將等待狀態與單個鎖的結構解耦（Decouple）。在傳統設計中，等待佇列是鎖的一部分；而在 Turnstile 設計中，每個執行緒在創建時都會被分配一個專屬的 Turnstile。
當執行緒在競爭鎖定而被迫阻塞時，它會將自己預先分配的 Turnstile 「捐贈」給該鎖，並透過一個以鎖的虛擬位址為鍵值的全域分桶雜湊表（Global bucketed hash table）進行映射。這種設計讓未競爭的鎖（Uncontended locks）可以保持極小的體積（有時僅為單個位元組或字組），而將繁重的同步管理工作移至外部的雜湊表中。這使得系統能動態地遍歷優先級繼承鏈，同時維持記憶體的高效利用。
然而，這種設計存在典型的工程權衡。雖然大幅降低了單個鎖的記憶體 footprint，但在高競爭環境下，執行緒必須從本地快取存取轉向全域雜湊桶的查找，並增加匯流排同步壓力，這可能導致雜湊桶本身的鎖競爭成為新的效能瓶頸。
現代系統的繼承與實作
這種「將同步狀態外部化」的設計模式，已成為現代高效能運行時的標準做法。以 Go 語言為例，其運行時需要管理數百萬個 goroutine 的併發，不能允許同步原語（Primitives）導致記憶體膨脹。Go 在 sema.go 中實作了內部運行時信號量，並使用一個名為 semtable 的全域根表。當 goroutine 阻塞時，其記憶體位址會被雜湊到特定的 semaRoot 桶中，並連結到等待結構 sudog 的 treap 樹中。這使得 Go 的同步變數能保持極輕量，支持大規模併發擴展。
在網頁瀏覽器領域，記憶體效率同樣至關重要。WebKit 引入了 WTF::ParkingLot 機制，這是一種可移植的用戶層「停車」機制。WebKit 將標準鎖的體積縮小，當執行緒需要阻塞時，它會將自己「停泊」在由 ParkingLot 管理的全域併發雜湊表中。這將鎖定動作與睡眠/喚醒機制完全分離，剔除了未競爭狀態下的冗餘開銷。
這種影響甚至延伸到了 Rust 生態系。知名的 parking_lot crate 便是明確移植了 WebKit 的 ParkingLot 設計。透過維護一個以鎖位址為鍵值的外部全域等待佇列雜湊表，該庫讓同步原語保持極小體積，同時在性能與公平性上超越了標準的作業系統原語。
技術啟示與總結
從 Solaris 的 Turnstile 到 Go 的 semtable 以及 Rust 的 parking_lot，其底層邏輯完全一致：將執行緒協調的繁重工作隔離到共享的外部數據結構中，讓個體鎖保持精簡、快速且廉價。這種設計模式證明了在系統設計中，透過解耦狀態管理與操作對象，可以在記憶體開銷與執行效能之間找到更好的平衡點。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。