定位與測試併發 Bug (Locating and Testing Concurrency Bugs)

Overview Table

程式碼評審——發現潛在錯誤

最直接的定位手段是看程式碼,但要徹底找出併發問題,需要投入大量時間仔細梳理,而非休閒時掃一眼:

• 請同事/同伴評審:非作者會從不同角度思考「這段程式怎麼工作」,覆蓋作者沒想到的情況(勿上傳機密程式碼到網路)。
• 放置一段時間再自審:先去做別的事,回頭再看會「有點陌生」,能以旁觀者角度審視。
• 向他人詳細解釋:對象可以是玩具熊或橡皮鴨;逐行解釋「接下來會發生什麼、哪些資料被存取」,自問自答往往能揭露問題。寫詳細註解也有同樣效果。

評審多執行緒程式碼的問題清單

定位併發相關的錯誤

多執行緒測試比單執行緒難好幾個數量級,因為執行緒排程不確定:相同輸入,結果可能時對時錯(例如程式碼中潛藏條件變數時)。定位的核心策略是縮小問題範圍:

• 單執行緒化測試:透過執行緒池的執行緒數參數、或手動改成單執行緒執行。單執行緒下問題仍出現 → 是一般 bug,而非併發 bug。
• 單核 vs 多核:問題在單核/單處理器系統上消失、在多核/多處理器系統上出現 → 幾乎可斷定是併發 bug(條件變數、同步或記憶體順序 (memory ordering) 問題)。
• 細粒度測試:分別對佇列的 push() 與 pop() 做併發測試,優於一次測試整個佇列的全部功能——出問題時更容易剔除嫌疑。

以併發佇列為例的測試情境清單

還要考慮測試環境因素:

1. 「多執行緒」是幾個執行緒(3、4,還是 1024)?
2. 系統是否有足夠的處理器讓每個執行緒跑在自己的核心上?
3. 測試要在哪種處理器架構上執行?
4. 如何合理安排測試中的「同時」?(見下方〈建構多執行緒測試程式碼〉)

可測試性設計

多執行緒程式的可測試性比單執行緒更重要,因為情況複雜得多。容易測試的程式碼通常滿足:

• 每個函式和類別的職責關係清楚;
• 函式短小精悍;
• 測試用例可完全控制受測程式碼周邊的環境;
• 執行特定操作的程式碼集中而非分散;
• 寫程式之前就想好怎麼測試(用什麼輸入、什麼情況會出錯、如何激發潛在問題)。

去併發化測試 (de-concurrency)

併發測試的最佳策略之一:把併發拆掉再測。

• 多執行緒狀態機 → 拆成若干邏輯狀態,單執行緒驗證每個輸入事件/轉換的正確性(輸入事件在真實系統中來自其他執行緒);核心狀態機與訊息路由的程式碼再另外保證事件依正確順序傳遞。
• 資料處理 → 分割成「讀共享資料 / 變換資料 / 更新共享資料」三塊,中間的變換部分就能用單執行緒測試;麻煩的多執行緒測試縮小到只剩「讀」與「更新」。

多執行緒測試技術

建構多執行緒測試程式碼

測試中「同時」的安排是核心難題。每個測試可拆成四個部分:

1. 環境布置程式碼(最先執行,如建立佇列);
2. 執行緒設置程式碼(在每個執行緒上執行,如預先建構高開銷的物件,避免影響測試結果);
3. 需要並發執行的受測程式碼;
4. 並發結束後的斷言檢查(驗證最終狀態)。

以「一執行緒在空佇列 push()、同時另一執行緒 pop()」為例,合法結果有兩種:pop() 取回推入的資料且佇列變空;或 pop() 回報佇列為空、但 push() 已成功推入一筆。不允許的是:回報空的同時佇列其實有資料,或取回資料後佇列還有殘留。若 pop() 是阻塞式,測試更簡單:斷言「彈出值 == 推入值」且「佇列為空」。

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

void test_concurrent_push_and_pop_on_empty_queue() {
  threadsafe_queue<int> q;                            // 1 環境布置
  std::promise<void> go, push_ready, pop_ready;       // 2 就緒/開始信號
  std::shared_future<void> ready(go.get_future());    // 3 go 的共享 future
  std::future<void> push_done;                        // 4 完成信號(在 try 外宣告)
  std::future<int> pop_done;
  try {
    push_done = std::async(std::launch::async,        // 5
      [&q, ready, &push_ready]() {
        push_ready.set_value();                       //   我就緒了
        ready.wait();                                 //   等 go 信號
        q.push(42);
      });
    pop_done = std::async(std::launch::async,         // 6
      [&q, ready, &pop_ready]() {
        pop_ready.set_value();
        ready.wait();
        return q.pop();                               // 7 經 future 回傳彈出值
      });
    push_ready.get_future().wait();                   // 8 等兩個執行緒都就緒
    pop_ready.get_future().wait();
    go.set_value();                                   // 9 按下「開始」鍵
    push_done.get();                                  // 10 等待完成
    assert(pop_done.get() == 42);                     // 11 斷言檢查
    assert(q.empty());
  } catch (...) {
    go.set_value();                                   // 12 異常時也要放行,避免死結
    throw;
  }
}

主執行緒                     push 執行緒               pop 執行緒
   │ 建立佇列 q、go/ready
   ├─ async 啟動 ──────────► push_ready.set_value()
   ├─ async 啟動 ──────────────────────────────────► pop_ready.set_value()
   │ 等 push_ready、pop_ready     ready.wait() 阻塞        ready.wait() 阻塞
   │ go.set_value() ───────────► q.push(42)   ──同時──►  return q.pop()
   │ push_done.get()
   │ assert(pop_done.get()==42); assert(q.empty())

設計要點:

• go 信號:一個 std::promise<void> go,每個執行緒持有其 std::shared_future(以值捕獲拷貝)並在上面 wait();主線程等所有 ready promise 都設值後才 go.set_value()——確保所有執行緒同時解除阻塞開跑。
• 為什麼需要它:啟動執行緒很耗時,若沒有 go 信號,push 執行緒可能在 pop 執行緒啟動前就跑完了,測試就失去「並發」的意義。
• 用 std::async 而非 std::thread:std::launch::async 保證每個任務有自己的執行緒;且 future 的解構函式會等待(匯入)任務完成,異常時更安全。
• future 宣告在 try 塊之外:異常發生時先 go.set_value() 再重拋⑫——否則等待 go 的執行緒永遠阻塞,future 解構時等它們 → 測試程式自己死結。
• 此模式容易擴展到兩個以上的執行緒:每個執行緒加一個 ready promise 即可。

測試多執行緒程式碼的性能

使用併發的初衷是利用更多處理器核心提升效率,所以性能測試與正確性測試同樣重要:

• 可擴展性 (scalability):希望程式在 24 核機器上跑出接近 24 倍的處理能力。依 Amdahl 定律(見 8.4.2 節),只要有重要程式碼以單執行緒(串行)方式執行,加速比就被鎖死——分析後可能發現 24 核的理論上限只有 3 倍。測試前先回顧設計結構再對照實測。
• 競爭 (contention) 的權衡:處理器太少 → 執行緒排隊等待;處理器太多 → 對資料的競爭反而使等待變久。性能不必然隨核數單調上升。
• 實測不同配置:在對應系統上以不同執行緒數/核數組合實測,畫出性能曲線圖;最起碼要在單處理器系統與多處理器(多核)系統上各測一次。

Exam/Test Patterns

Related Notes

• 11-Testing-and-Debugging/01-Concurrency-Bug-Types
• 11-Testing-and-Debugging/Practice-Testing-and-Debugging
• 06-Lock-Based-Data-Structures/02-Thread-Safe-Stack-and-Queue
• 04-Synchronizing-Operations/02-Futures-and-Asynchronous-Tasks
• 05-Memory-Model-and-Atomics/04-Memory-Ordering-Options
• 08-Designing-Concurrent-Code/04-Exception-Safety-and-Scalability