測試與除錯練習題 (Practice - Testing and Debugging)

兩大類:不必要的阻塞與競爭條件。

• 不必要的阻塞:死結 (deadlock)、活結 (livelock)、I/O 阻塞/外部輸入。
• 競爭條件:資料競爭 (data race)、破壞不變量、生命週期問題。

死結是執行緒阻塞等待互相持有的資源;活結的執行緒不是阻塞,而是在迴圈中持續檢查(如自旋鎖)。
快速判別:CPU 使用率——死結時 CPU 低,活結時 CPU 居高不下。不嚴重的活結可用隨機排程化解。

1. 懸空指標:要存取的資料已被其他執行緒刪除;
2. 隨機記憶體錯誤:局部更新導致執行緒讀到不一致的資料;
3. 雙重釋放:如兩個執行緒同時對同一佇列 pop(),刪除同一筆關聯資料。
   這是「基於資料」的問題;操作間有順序依賴卻未正確同步時也會發生(破壞存取順序)。

因為測試環境可能與部署環境不同,問題根本不會在測試機上出現:

• 經典案例:單處理器系統上測多執行緒,一切實際串行,競爭條件與快取乒乓不會出現;
• 架構差異:x86 上原子載入無論 memory_order_relaxed 或 seq_cst 通常是同一條指令,錯誤的 relaxed 用法要到 SPARC 等記憶體順序更精細的架構上才爆發。
  另外,受測物件太大時排程序列過長,再多次執行也難覆蓋。跨平台應用必須在相關平台上實測。

用特殊軟體模擬執行環境,記錄資料存取序列、上鎖與原子操作,再依 C++ 記憶體模型規則窮舉重跑所有可能的排程組合,識別競爭條件與死結——對受測範圍是徹底的檢查。
不適合整個應用,因為組合數隨執行緒數與操作數呈指數成長,耗時過長;只適合細粒度的程式碼段,且依賴模擬軟體的可用性。

1. 環境布置程式碼(最先執行,如建立佇列);
2. 執行緒設置程式碼(在每個執行緒上執行;高開銷物件在此預先建構,避免干擾測試);
3. 需要並發執行的受測程式碼;
4. 並發結束後的斷言檢查(如 assert(pop_done.get()==42)、assert(q.empty()))。

單執行緒下正常 → 排除一般(非併發)bug;單核消失、多核出現 → 幾乎可斷定是併發 bug。
下一步優先檢查:條件變數的使用、執行緒間同步、記憶體順序 (memory ordering) 是否正確(如錯用 relaxed 原子操作、共享資料未加鎖)。可搭配專用庫檢測或對可疑區段做組合模擬測試。

使用 go 信號 + ready futures 模式(代碼11.1):

• 建立 std::promise<void> go 與 std::shared_future<void> ready(go.get_future()),每個測試執行緒以值拷貝 ready;
• 每個執行緒各有一個 ready promise(push_ready/pop_ready):先 set_value() 表示就緒,再 ready.wait() 阻塞;
• 主執行緒等所有 ready promise 就緒後才 go.set_value(),所有執行緒同時解除阻塞。
  因為啟動執行緒很耗時,沒有 go 信號時 push 執行緒可能在 pop 執行緒啟動前就完成,測試便失去並發意義。異常時必須 go.set_value() 再重拋,避免測試程式自己死結。

lock-free 佇列:細粒度、正確性極難靠肉眼保證 → 組合模擬測試(必要時輔以蠻力壓測)。
整個伺服器應用:模擬窮舉不可行 → 專用庫檢測 + 蠻力測試,並在多種硬體配置(單核/多核/目標架構)上執行。

阻塞型:表現為掛起、無回應、任務超時,狀態停在現場——可直接用除錯器附掛 (attach) 到卡住的執行緒觀察誰持有/等待哪把鎖,重現性較穩定。
競爭型:表現為隨機崩潰、錯誤輸出,依賴執行時序而時對時錯;破壞現場(被覆寫的記憶體)往往離肇因很遠,難以定位。
「詛咒」的原因:應用中任何執行緒都可能覆寫其他執行緒可存取的資料,事後除錯幾乎無從追起——必須事前預防:限制執行緒可存取的資料範圍、正確使用同步,並以評審清單+可測試性設計把問題擋在前期。