Scheduler Activations
Scheduler Activations 是一套讓 kernel 和 user-level thread library 能夠雙向溝通的機制，專門用來解決 Many-to-Many Model 和 Two-level Model 中 kernel 與 library 各自為政的問題。
動機：為什麼需要溝通？
在 M:N 或 Two-level model 裡，user-level thread library 負責把 N 個 user thread 排程到 M 個 kernel thread 上。但 kernel 和 library 各自做決策，彼此看不到對方在幹什麼。
典型的失敗場景：某個 user thread 執行了 blocking syscall，kernel 把對應的 kernel thread 擋住，但 library 完全不知情，以為那個 kernel thread 還在正常執行，導致 map 到它上面的其他 user thread 白白等著，明明其他 kernel thread 是空閒的。
根本原因：kernel 和 user-level library 之間缺乏溝通管道。
兩個核心機制
Lightweight Process (LWP)
LWP 是 user thread 和 kernel thread 之間的中間抽象層， 扮演「virtual CPU」的角色：
User Thread
↓
[LWP] ← user-level library 把 user thread schedule 到這裡
↓
Kernel Thread
User-level library 操作的對象是 LWP 而非 kernel thread， 有了更清晰的介面。每個 LWP 背後對應一個 kernel thread。
Upcall
一般 syscall 是 user → kernel 的單向溝通，而 upcall 是反方向的——kernel 主動通知 user-level library說「發生了某件事，你需要重新做 scheduling 決策」。
一般方向： User → [syscall] → Kernel
Upcall： Kernel → [upcall] → User-level thread library
典型的 upcall 場景：
- 某個 kernel thread 因 blocking I/O 被暫停 → kernel upcall 通知 library → library 把該 LWP 上的 user thread 搬走
- I/O 完成，kernel thread 重新可用 → kernel upcall 通知 library → library 重新分配工作
為什麼 M:N model 最終不流行
LWP 解決了「介面」問題，upcall 解決了「溝通」問題，但光是維護這套雙向通訊機制就已經相當複雜。這正是大多數現代 OS 最終回歸簡單的 One-to-One Model 的原因之一——用實作複雜度換來的彈性，在大多數場景下並不值得。