中斷執行緒 (Interrupting Threads)

Overview Table

為什麼需要中斷?(9.2)

長時間執行的執行緒常需被要求「提早停止」:結果已確定、發生錯誤、使用者取消、或池要銷毀。重點是讓執行緒主動、有秩序地停下(清理資源、保持資料結構一致),而非戛然而止。C++11 標準沒有提供此機制,但自行實作不難;統一機制比逐場景硬寫更易維護。

interruptible_thread 介面與基本實作(9.2.1,代碼 9.9)

介面 = std::thread 的介面(join()/detach()/joinable())再加一個 interrupt()。

核心機制:

• thread_local interrupt_flag this_thread_interrupt_flag —— 每條執行緒有自己的中斷旗標;interruption_point() 檢查的就是當前執行緒的這份 thread_local 資料
• 因為 thread_local 旗標必須「屬於新執行緒、卻能被擁有者設定」,不能直接用普通 std::thread 管理 —— 建構函式用 promise/future 把旗標位址傳回來:

template <typename FunctionType>
interruptible_thread(FunctionType f) {
    std::promise<interrupt_flag*> p;
    internal_thread = std::thread([f, &p] {
        p.set_value(&this_thread_interrupt_flag);  // 新執行緒回報旗標位址
        f();
    });
    flag = p.get_future().get();                   // 等到位址才返回
}
void interrupt() { if (flag) flag->set(); }

• Lambda 引用區域變數 p 沒有懸空問題:建構函式會等 future 就緒才返回,屆時 p 已不再被引用
• 需注意在執行緒退出或 detach 前避免 flag 懸空(書中實作未處理 join/detach 細節)

檢查中斷:interruption_point()(9.2.2)

void interruption_point() {
    if (this_thread_interrupt_flag.is_set())
        throw thread_interrupted();
}

在迴圈等安全的地方顯式呼叫(例:while (!done) { interruption_point(); process_next_item(); })。

中斷條件變數等待(9.2.3,代碼 9.10–9.11)

天真版:interruption_point() → set_condition_variable(cv)(讓 interrupt_flag::set() 能 notify_all() 喚醒等待者)→ cv.wait(lk) → 清除關聯 → 再檢查。有兩個問題:

1. 異常安全:cv.wait() 可能拋出異常,直接離開函式而沒清除旗標與條件變數的關聯 → 修法:用 RAII 結構(clear_cv_on_destruct)在解構時清除
2. 競爭條件 (race condition):最後一次 interruption_point() 檢查之後、cv.wait() 真正開始等待之前,若旗標被設定並 notify_all(),通知會遺失(執行緒還不在等待狀態)→ 之後就再也叫不醒了

實務解法(代碼 9.11):放棄「完美喚醒」,改用超時等待 cv.wait_for(lk, 1ms) —— 就算通知遺失,最多 1ms 後醒來檢查旗標,把等待的上限交給時鐘。

• interrupt_flag 成員:std::atomic<bool> flag、std::condition_variable* thread_cond、std::mutex set_clear_mutex
• set():先 flag.store(true, memory_order_relaxed),再鎖 set_clear_mutex、若 thread_cond 非空則 notify_all()
• 帶述詞版把 1ms 超時完全藏進迴圈:

while (!this_thread_interrupt_flag.is_set() && !pred())
    cv.wait_for(lk, std::chrono::milliseconds(1));

代價:虛假喚醒與述詞檢查次數大增。

用 condition_variable_any 徹底解決(9.2.4,代碼 9.12)

std::condition_variable_any 可搭配任意符合 Lockable 的鎖,不限 std::unique_lock<std::mutex> —— 於是可以設計 custom_lock,把 interrupt_flag 內部的 set_clear_mutex 與使用者的鎖綁在一起:

custom_lock 生命週期            持有的鎖
建構        lock(set_clear_mutex) + 設 thread_cond_any   [兩把都鎖住]
cv.wait(cl) 內部 unlock() → 同時解 lk 與 set_clear_mutex  [進入等待,原子地]
喚醒        lock() → std::lock(set_clear_mutex, lk)      [兩把一起鎖回]
解構        清 thread_cond_any + 解 set_clear_mutex

• 競爭為何消失:interrupt() 的 set() 必須先取得 set_clear_mutex 才能通知;而 custom_lock 從「檢查中斷」到「wait 進入等待狀態」全程持有 set_clear_mutex → 旗標若已設定,必然在檢查時看見;若還沒設定,notify_all() 必然發生在等待開始之後 → 通知不可能遺失,不需 1ms 輪詢
• lock() 用 std::lock(self->set_clear_mutex, lk) 同時鎖兩把,避免死結
• 解構函式清掉 thread_cond_any 指標並解鎖,之後可再次檢查中斷

中斷其他阻塞呼叫(9.2.5)

互斥鎖、future 等阻塞沒有「掛上通知」的入口,一般只能沿用超時輪詢:

template <typename T>
void interruptible_waitfuture<T>& uf {
    while (!this_thread_interrupt_flag.is_set()) {
        if milliseconds(1) ==
            std::future_status::ready) break;
    }
    interruption_point();
}

處理中斷:異常 + catch(9.2.6)

中斷在被中斷執行緒眼中就是 thread_interrupted 異常,用標準 catch 處理即可;處理完後若再被 interrupt(),下個中斷點 (interruption point) 會再拋 —— 適合「一系列獨立任務,中斷即放棄當前任務、續做下一個」的模型。

• 異常安全注意事項照舊適用:確保資源不洩漏、資料結構留下一致狀態
• 未捕獲的 thread_interrupted 傳進 std::thread 解構時會呼叫 std::terminate() 終止整個程式 → interruptible_thread 的包裝 lambda 中把 f() 包進 try { f(); } catch (thread_interrupted const&) {},保證未處理的中斷也異常安全

應用退出時中斷後台執行緒(9.2.7,代碼 9.13)

桌面搜尋類應用:GUI 執行緒保持回應,後台執行緒監視檔案系統、更新索引,直到應用退出。

for (auto& t : background_threads) t.interrupt();  // 1. 先全部發中斷
for (auto& t : background_threads) t.join();       // 2. 再逐一等待

• 後台迴圈每輪呼叫 interruption_point() 檢查中斷
• 為何不「中斷一個就 join 一個」? 並發!被中斷的執行緒不會立即結束(要走到下個中斷點、執行解構與異常處理)。先發完所有中斷,各執行緒可並行處理自己的中斷,整體退出更快

 主執行緒                       後台執行緒 (每一條)
 interrupt() ──► set flag ──►  ... 下一個 interruption_point()
 interrupt() ──► set flag        └─ throw thread_interrupted
     │                              └─ 解構/清理 → catch → 執行緒結束
 join() ◄────────────────────────────┘ (所有執行緒並行清理)

Exam/Test Patterns

Related Notes

• 09-Advanced-Thread-Management/01-Thread-Pools
• 09-Advanced-Thread-Management/02-Work-Stealing-and-Queue-Contention
• 09-Advanced-Thread-Management/Practice-Advanced-Thread-Management
• 04-Synchronizing-Operations/01-Condition-Variables-and-Thread-Safe-Queue
• 04-Synchronizing-Operations/03-Waiting-with-Time-Limits
• 02-Thread-Management/01-Launching-and-Joining-Threads