Thread Sync #1. 概念篇 - 如何化被動為主動?
摘要提示
- 問題背景: 遊戲與互動流程常被主迴圈牽制，導致邏輯被迫切割與複雜化
- 思維落差: 線性思維寫不出主動互動流程，必須被動回應主程式呼叫
- 狀態機拆分: 以 Tetris 為例，直覺流程被拆成多段以狀態處理
- 猜數字架構: GameHost 主導、Player 被動，導致跨回合資料與流程斷裂
- 回呼限制: 將主動權移給 Player 雖可減痛，但不符合主持-來賓與對戰場景
- 多執行緒解套: 各自擁有「思路」，以兩個執行緒並行更貼近真實互動
- 重點轉移: Thread 不只為效能，也可用來簡化流程與溝通模型
- 同步機制: 以共用變數 + AutoResetEvent 協調資料交換與時機
- 時序觀念: 問與答兩個方向須交換 Wait/Set 角色，確保正確對接
- 系列預告: 本篇談概念，下篇提供實作與程式碼示例
全文重點
作者從參與猜數字遊戲的程式設計題聯想到一個常見難題：當程式被主迴圈掌控時，直覺的、連貫的業務流程會被迫打散成許多小段，透過狀態在每次迴圈中被動執行，結果就是思路被切斷、維護困難。以遊戲開發為例，像 Tetris 這類需要持續渲染的應用，通常會在固定間隔刷新畫面，因此邏輯必須分割成可被重入呼叫的小塊，仰賴狀態機拼湊出原本的流程。作者將此困境延伸到黑暗程式魔人的猜數字比賽：GameHost 是「老大」，Player 必須在每回合被呼叫一次，上一回合的問題要到下一回合才拿到答案，迫使開發者把一段原本可以順流思考的策略拆成許多回合的微操作，額外承擔「行政成本」。
嘗試用 callback 讓 Player 轉為主動雖然表面上能減少痛苦，但概念上不對等：主持人不應等來賓訪問，若未來是雙方 Player 對戰也會陷入「誰是老大」的僵局。作者因此提議用多執行緒思路重構：讓 GameHost 與 Player 各自擁有獨立的「思路」與流程，彼此透過同步機制在適當時機交換資料，如此一來雙方都能以直覺方式撰寫程式，更貼近真實世界的互動模型（莊家與玩家不會共用同一個腦袋）。
在此脈絡下，執行緒不再只是提升效能的工具，而是用來簡化流程與溝通的抽象機制。技術上可用共用變數配合 AutoResetEvent 進行同步：需要資料的一方先 Wait()，提供資料的一方在寫入共用變數後呼叫 Set() 喚醒對方繼續。因為資料交換有方向性（如題目從 Player 到 Host，答案由 Host 到 Player），雙方需在不同階段適時互換 Wait/Set 的角色。作者最後預告下一篇將提供實作細節與程式碼，讓讀者把概念落地。
段落重點
緒論：不是勵志，是執行緒同步與流程問題
作者澄清本文非勵志，而是從一場猜數字比賽延伸到執行緒同步的概念與應用。動機源於在設計過程中意識到：當系統主導權在外部（如 Host、主迴圈）時，內部模組（如 Player）的直覺策略會被迫切割成被動回應的片段。作者想藉由 Thread Sync 的概念，討論如何讓「被呼叫者」能以更主動、更自然的思路完成任務，同時不破壞整體架構的控制權，並鋪陳後文的技術手法。
線性思維與遊戲迴圈的落差
多數開發者的思考是線性的：「先做 A，再做 B，條件滿足做 C」。但諸如遊戲這種需要固定頻率刷新畫面的應用，主程式會長期運行在無窮迴圈中。此時，直覺流程無法直接落地，只能拆解為多個狀態與事件處理器，於每次迴圈中被動執行一小步。這種架構將原本簡潔的邏輯撕裂成片段，開發者必須負擔跨迴圈維持上下文的一切細節，思路成本與維護成本大幅上升。
俄羅斯方塊範例：被迫切割邏輯與狀態機
以作者早年撰寫的 Tetris 為例：理想流程是「方塊下落、玩家輸入即時移動或旋轉、直至落定」。但在單執行緒且由主迴圈驅動的情境，邏輯必須切成許多 Case（上下左右、旋轉、加速等），每次迴圈按狀態執行一段，再以多次呼叫拼回完整行為。這樣的狀態機雖可運作，卻讓原本清晰的因果關係變成碎片化的事件回應，語意分散且不易推理，也使新手更難在程式中找到「流程的連續性」。
猜數字 GameHost/Player 架構的困境
黑暗魔人的題目採用 GameHost（主持）與 Player（參賽者）的抽象。Host 定期呼叫 Player.GuessNum()，並將上一回合的回應傳入。看似簡單，卻使 Player 的整體策略被迫拆為「每回合一小步」，甚至面臨「這回合問的，下回合才拿到答案」的延遲耦合。開發者要在高度切碎的時間軸中維持策略狀態、候選空間、推理進度等，思考負擔與錯誤機率俱增。這是典型的「邏輯被被動化」的痛點。
回呼與「誰是老大」的問題
作者曾考慮讓 Host 提供 callback 以便 Player 主動提問，將控制權部分下放，讓 Player 以更自然的方式進行推理；然而從系統角色上不合理：主持者不應變成被動等待者。如果未來擴展為 Player 對戰，更會陷入「兩邊都想主動」的僵局。回呼雖能局部舒緩被動問題，但未從模型本質解決「雙方流程各自連貫、彼此協調」的需求，因此不是長久之計。
以兩個執行緒重構思路與時序差異
作者提出核心解法：讓 Host 與 Player 各自擁有獨立執行緒，分別維持完整的思路與流程，並在必要時同步交換資訊。對照時序圖可見差異：舊法以單一時鐘切片各方行為，新法則讓兩邊各自連續思考，只在關鍵節點對齊。此舉使兩方的程式碼更貼近直覺與真實世界（莊家與玩家不共用腦袋），也更易表達複雜策略。先解決思維模型的合理性，才有空間把演算法做複雜化與最佳化。
Thread 不是只為效能：同步與 AutoResetEvent 交換資料
本文強調執行緒的用途不僅是效能，還是「簡化流程、分離思路、規範溝通」的手段。技術上透過共用變數搭配同步原語來協調節點：需要資料的一方呼叫 Wait() 進入等待；資料準備好的一方寫入共用變數後呼叫 Set() 喚醒對方。作者特別提到 AutoResetEvent：喚醒單一等待者且自動重置，適合一問一答的點對點模式。由於互動有方向性（問題流向與答案流向相反），雙方需在不同階段對調 Wait/Set 的角色，才能保證資料交握無誤。
結語與下集預告
作者總結：使用多執行緒並不等於追求吞吐，而是為了讓各模組保持自然思考與連續流程，將被動拆分的複雜度轉為明確同步點的管理。當模型被簡化、思路更直覺，才有餘裕精進策略本身。本文先談概念與設計思維，避免陷入細節；下一篇將端出實作與程式碼，示範如何以 AutoResetEvent 等機制在 .NET 中落地雙執行緒協作與資料交換。
資訊整理
知識架構圖
- 前置知識：
- 程式基本控制流程與事件驅動觀念
- 物件導向：抽象化、介面/抽象類別、多型
- 多執行緒基礎：Thread/ThreadPool、共享狀態、同步原語
- 遊戲迴圈與狀態機基本概念
- .NET 同步機制：AutoResetEvent/ManualResetEvent 的 Wait/Set
- 核心概念：
- 被動式流程 vs 主動式思考：從被主程式輪詢驅動，轉為每方可維持自身連貫思路
- 多執行緒用於簡化思考而非僅為效能：用兩個執行緒分別承載 GameHost 與 Player 腦袋
- 同步與溝通：共享變數 + AutoResetEvent 的 Wait/Set 以實作「你準備好了嗎？」
- 回合制交握：問題流向 player→host、答案流向 host→player，角色依資料方向交換
- 設計邊界：避免以 callback 顛倒主從，維持清晰主持/來賓角色下的對等互動
- 技術依賴：
- .NET 執行緒與同步原語：AutoResetEvent 依賴 OS 事件機制
- 共享狀態的正確性：需要臨界區保護和可見性保障
- OOP 多型與協作：GameHost 依賴 Player 抽象介面；互動協定以同步原語落實
- 時序正確性：Wait/Set 的配對次序、避免遺失訊號或死結
- 應用場景：
- 遊戲開發：將玩家邏輯與引擎/主持流程分執行緒協作
- 互動式系統：問答/回覆、回合制協定、流程引擎
- 生產者-消費者或交替工作：雙向資料交換的同步
- 需要維持連貫業務思路但受外部主迴圈驅動的程式
學習路徑建議
- 入門者路徑：
- 了解單執行緒遊戲迴圈為何迫使邏輯被拆碎（輪詢、狀態機）
- 學會 .NET 的 AutoResetEvent 基本用法：WaitOne/Set 的效果
- 寫一個最小範例：兩個執行緒用共享變數 + 事件傳一問一答
- 進階者路徑：
- 設計 GameHost 與 Player 的抽象界面與互動契約（問題/答案的資料結構）
- 規劃雙向同步：分別為「題目就緒」與「答案就緒」設計對應事件
- 面對競態條件、訊號遺失、時序顛倒與死結的防護（例如加入超時、重試、狀態檢查）
- 實戰路徑：
- 實作兩執行緒版猜數字：Host 與 Player 各自維持直覺流程，用 AutoResetEvent 交握
- 加入記錄與診斷：時序圖、日誌、事件觸發點標註，驗證沒有競態與阻塞
- 延伸到 Tetris 或回合制遊戲：用事件取代輪詢，讓行為以「主動」觸發而非「被動」切片
關鍵要點清單
- 被動式邏輯切片的代價: 單執行緒主迴圈迫使邏輯拆分為多段輪詢執行，降低可讀性與維護性 (優先級: 高)
- 主動式思考的價值: 讓每一方維持連貫流程，貼近人類思考以降低認知負擔 (優先級: 高)
- 多執行緒不僅為效能: 使用執行緒來簡化設計與思考，而非僅追求平行化 (優先級: 高)
- AutoResetEvent 基本機制: 以 Wait/Set 實作「誰先等、誰喚醒」的一次性訊號 (優先級: 高)
- 共享變數的可見性與競態: 傳遞資料時需考量同時存取與記憶體可見性 (優先級: 高)
- 雙向資料交換設計: 問題與答案各有對應事件，避免方向混淆 (優先級: 高)
- 時序圖思維: 以時序圖檢視交握，釐清誰先等誰先設置資料 (優先級: 中)
- 避免遺失訊號: 在 Wait 之前設定好等待條件與狀態，確保 Set 不會被「丟失」 (優先級: 高)
- 超時與錯誤處理: Wait 增加超時與 fallback，避免永久阻塞 (優先級: 中)
- 多型與角色分離: GameHost 為主持、Player 為邏輯供應者，透過抽象介面互動 (優先級: 中)
- 不濫用回呼顛倒主從: 保持主持流程清晰，避免讓 callback 造成控制權混亂 (優先級: 中)
- 狀態機與事件整合: 將狀態轉移改由事件驅動，減少輪詢與硬拆 (優先級: 中)
- 測試與觀測性: 以日誌、事件計數、診斷工具驗證沒有死結與競態 (優先級: 中)
- 可擴充性考量: 從單一 Host-Player 擴展到對戰、多方互動時的同步策略 (優先級: 低)
- 與 ThreadPool 的關聯: 理解 AutoResetEvent 在 ThreadPool 工作協調中的類似用法 (優先級: 低)
