ThreadPool 實作 #3. AutoResetEvent / ManualResetEvent

摘要提示

• 排程策略: Thread Pool 可採「主動指派一條等待最久的執行緒」或「交給作業系統排程搶工作」兩種策略
• OS 排程優勢: OS 掌握優先序、GC、虛擬記憶體等脈絡，常較應用層手動喚醒更有效率
• AutoResetEvent: 每次 Set 只喚醒一條等待中的執行緒，模擬先到先贏的序列化喚醒
• ManualResetEvent: 一次 Set 可喚醒所有等待中的執行緒，讓 OS 決定誰先跑
• 實驗結果: AutoResetEvent 使喚醒訊息逐秒一條出現；ManualResetEvent 則一次全出現、順序隨機
• SimpleThreadPool 應用: 用 ManualResetEvent 同步佇列通知，讓所有 worker 齊解鎖，由 OS 競速搶任務
• 策略切換: 想用排隊先贏改 AutoResetEvent；想微調 thread priority 強化 OS 排程效益用 ManualResetEvent
• 可擴充性: 以 WaitHandle 型別一行差異，即可調整整體 Thread Pool 行為
• 資源收斂: 透過旗標與 WaitOne 超時控制 worker 生命週期與退出
• 實作重點: 任務佇列、動態建工、喚醒通知、終止/取消機制構成簡易 Thread Pool

全文重點

本文延續 Thread Pool 實作，聚焦「如何喚醒等待中的 worker threads 接工作」的策略。作者指出兩條路：一是 Thread Pool 主動決定喚醒哪一條（例如選等待最久者），二是讓所有等待中的 worker 同時解鎖，交給作業系統（OS）排程決定誰先跑。乍看主動挑選較合理，但實務上 OS 掌握更多排程資訊（如執行緒優先序、GC 停頓、是否被換出到虛擬記憶體等），應用程式層強行叫醒某條執行緒反而可能增加切換成本。

技術上，兩種策略幾乎只差一行：選擇 AutoResetEvent 或 ManualResetEvent。AutoResetEvent 每次 Set 只喚醒一條等待中的執行緒，對應「先到先贏」與序列化喚醒；ManualResetEvent 則一次 Set 可喚醒所有等待者，等同把所有 worker 從 blocked 推進到可執行狀態，由 OS 排程決定誰先取得 CPU、進而搶到工作。

作者以兩段簡短 C# 程式展示差異：AutoResetEvent 配合多次 Set 讓五條執行緒依序被喚醒，訊息逐秒出現；改用 ManualResetEvent 後僅一次 Set 即五條全被喚醒，訊息幾乎同時出現、順序隨機。將此套用在 SimpleThreadPool，當有新任務入列時用 ManualResetEvent.Set 一次喚醒所有 worker，誰先跑由 OS 決定，搶到任務者執行，其他沒搶到者再度待命。若要回到「先排隊先贏」的策略，只需把 WaitHandle 改為 AutoResetEvent。

文末提供約百行的 SimpleThreadPool 完整原始碼，核心包含：任務佇列 Queue、動態建立 worker（視佇列長度與上限）、用 ManualResetEvent 作為 enqueue 通知、Stop/Cancel 旗標控制收斂、WaitOne 設定超時決定 worker 生存、以及基本的 callback 執行與例外捕捉。作者強調，雖然僅一行差異（Auto vs Manual），卻牽動整體排程策略與效能表現；若需要依工作性質調整執行緒優先序、發揮 OS 排程優勢，ManualResetEvent 是更合適的選擇。

段落重點

兩種喚醒策略：主動指派 vs. 交給 OS

作者先說明從多個閒置的 worker thread 中選一個來接工作可以有兩種策略：由 Thread Pool 主動挑選（如誰等最久叫誰），或完全不挑，讓所有 worker 由 OS 排程搶工作。雖然直覺上主動選擇看似最佳，但 OS 才掌握實際的排程脈絡（優先序、GC、是否被換出等），應用程式層面不一定能做出更有效率的決策。於是「齊頭式平等喚醒，讓 OS 判定先後」往往更實際。

AutoResetEvent 示範：一次喚醒一條，序列化喚醒

範例以單一 AutoResetEvent 讓五條執行緒 WaitOne 阻塞後，主緒多次 Set，每次只喚醒一條等待中的執行緒，因此「wakeup」訊息會按每秒一次的節奏逐行輸出。這種行為對應到「先到先贏／每次一人」的喚醒模式，利於可控的序列化取工；若將其套進 Thread Pool，即意味著內部邏輯主導「誰先被喚醒、誰先拿工作」。

ManualResetEvent 示範：一次喚醒全部，交由 OS 排程

將型別換為 ManualResetEvent，其餘邏輯不變，主緒僅一次 Set 即喚醒所有等待中的執行緒。隨後各執行緒的「wakeup」訊息幾乎同時出現且順序隨機，因為真正的先後完全交由 OS 排程決定。若應用在 Thread Pool，等於把所有 worker 從 blocked 轉為可執行狀態，第一個被 OS 安排到 CPU 的執行緒最可能搶到任務，其他則在發現無工可做後再度休眠，等待下一輪通知。

策略選擇與實作建議

作者指出，選用哪個 WaitHandle 形同選擇整體排程策略：需要「先排隊先贏」時採用 AutoResetEvent；想依工作屬性調整 thread priority、把資源分配交給 OS 發揮時採用 ManualResetEvent。這個改動僅是一行程式，卻深刻影響 Thread Pool 的公平性、延遲與效能。範例中也刻意插入 Sleep 讓輸出節奏更清晰，幫助觀察兩者差異。

SimpleThreadPool 實作概要與關鍵點

完整原始碼展示一個約百行的 SimpleThreadPool：以 Queue 存任務，當佇列有量且 worker 未達上限時動態建新 worker；以 ManualResetEvent enqueueNotify 作為入列通知，一次喚醒所有等待的 worker；worker 迴圈在佇列非空時持續取出任務執行，捕捉例外；透過 _stop_flag、_cancel_flag 控制結束或取消佇列中任務；WaitOne 設置超時以決定 worker 是否退出，避免無限閒置。最後以 EndPool/CancelPool 收斂所有 worker。作者強調，若要改成「先到先喚醒」模式，只需把 enqueue 的通知從 ManualResetEvent 換成 AutoResetEvent 即可，達到以最小改動切換策略的目的。

資訊整理

知識架構圖

1. 前置知識：學習本主題前需要掌握什麼？
   • 作業系統排程基本概念（Running/Waiting/Blocked、優先權、GC/分頁對排程影響）
   • .NET 多執行緒基礎（Thread、ThreadPriority、WaitHandle、WaitOne/Set）
   • 事件同步元件的差異（AutoResetEvent vs ManualResetEvent）
   • 基本的佇列與臨界區（Queue、lock）
2. 核心概念：本文的 3-5 個核心概念及其關係
   • 事件通知模型：AutoResetEvent（單一喚醒）與 ManualResetEvent（群體喚醒）
   • 工作派發策略：先到先贏（公平、序列化喚醒） vs 交給 OS（齊頭式喚醒、由排程器決定）
   • OS 排程因素：優先權、GC 停頓、分頁/記憶體狀態，影響哪個 thread 抢先執行
   • ThreadPool 設計取捨：選擇不同事件型別就切換策略；可搭配調整 thread priority
   • 簡易 ThreadPool 實作：工作佇列、工人執行緒生命週期、停止/取消、超時等待
3. 技術依賴：相關技術之間的依賴關係
   • ThreadPool 工作派發 → 依賴 WaitHandle（Auto/ManualResetEvent）實現喚醒策略
   • 喚醒後誰先跑 → 依賴 OS 排程器（受 ThreadPriority、GC、記憶體狀態等影響）
   • 佇列存取 → 依賴 lock 保護臨界區，避免競態條件
   • 執行緒生命週期管理 → 依賴 WaitOne + timeout、Join、旗標（_stop_flag/_cancel_flag）
4. 應用場景：適用於哪些實際場景？
   • 需要公平、單點喚醒的工作派發（例如：確保一個工作只喚醒一個工人按序處理）
   • 需要高吞吐並交由 OS 排程最佳化的場景（大量工人同時競爭工作、依優先權搶先）
   • 需要依工作性質微調執行緒優先權的 ThreadPool 實作
   • 教學/原型：以簡化版 ThreadPool 理解事件同步、排程與派發策略

學習路徑建議

1. 入門者路徑：零基礎如何開始？
   • 了解 Thread、ThreadPriority、lock、Queue 基本用法
   • 練習 AutoResetEvent/ManualResetEvent 的 WaitOne/Set 行為與差異（小型範例）
   • 觀察不同喚醒策略對輸出順序與吞吐的影響
2. 進階者路徑：已有基礎如何深化？
   • 實作簡易 ThreadPool：工作佇列、工人執行緒、喚醒邏輯、停止/取消
   • 切換 AutoResetEvent/ManualResetEvent，測量延遲、吞吐、CPU 利用率
   • 依工作特性調整 ThreadPriority，觀察 OS 排程器在群體喚醒下的效應
3. 實戰路徑：如何應用到實際專案？
   • 針對工作負載選擇喚醒策略：低爭用用 AutoResetEvent、公平性 vs 高競爭/高吞吐用 ManualResetEvent
   • 封裝可配置的 WaitHandle 策略與優先權設定（策略模式）
   • 增加監控與保護：統計、超時、例外處理、Reset 行為、資源釋放與關閉流程

關鍵要點清單

• AutoResetEvent（單一喚醒）: 每次 Set 只喚醒一個等待中的執行緒，適合先到先贏/序列化喚醒策略 (優先級: 高)
• ManualResetEvent（群體喚醒）: 一次 Set 可喚醒所有等待中的執行緒，交由 OS 決定誰先跑，提升競爭度 (優先級: 高)
• 喚醒策略與排程: Auto 導向程式端控制公平；Manual 導向 OS 排程最適化（優先權、暫停、分頁） (優先級: 高)
• WaitOne/Set 基本語義: WaitOne 進入阻塞；Set 將事件設為有訊號，解除阻塞邏輯 (優先級: 高)
• ManualResetEvent 的 Reset: 使用 Manual 時需在適當時機 Reset，避免事件長期為有訊號造成忙迴圈或誤喚醒 (優先級: 高)
• ThreadPriority 的作用: 在群體喚醒下，優先權影響誰先被 OS 調度到 Running (優先級: 中)
• GC/分頁對排程的影響: GC 停頓與分頁可能讓特定執行緒延後，交給 OS 決策更具全局資訊 (優先級: 中)
• 佇列存取與 lock: Dequeue 時需 lock 保護，避免競態與空取 (優先級: 高)
• 工人執行緒動態建立: 當工作堆積且工人數未達上限時再建立新工人，平衡成本與吞吐 (優先級: 中)
• 超時等待與生命週期: WaitOne(Timeout) 控制工人閒置與退出時機，避免無限等待 (優先級: 中)
• 停止與取消旗標: _stop_flag/_cancel_flag 協調優雅關閉與取消待處理工作 (優先級: 中)
• 例外處理邊界: 工作執行需捕捉例外避免工人崩潰，並考慮記錄與復原策略 (優先級: 中)
• 觀察輸出順序驗證行為: Auto 下逐一喚醒、Manual 下一次全喚醒且順序隨機，利於理解策略差異 (優先級: 低)
• 策略可替換性: 僅需切換 WaitHandle 型別即可從公平轉為 OS 決策的競爭策略 (優先級: 高)
• 專案化建議: 封裝 ThreadPool 配置（喚醒策略、優先權、上限、超時）並加入監控度量 (優先級: 中)