同步操作練習題 (Practice - Synchronizing Operations)

等待中的執行緒必須在等待期間解鎖互斥鎖、被喚醒後重新上鎖再檢查條件;std::lock_guard 沒有這種中途解鎖/再上鎖的彈性。若休眠期間仍持鎖,生產者永遠無法上鎖推入資料。
虛假喚醒 (spurious wakeup):等待執行緒可能並非回應 notify 而醒來,次數與頻率不確定 → 必須以 predicate 重新檢查條件(wait(lk, pred)),且 predicate 不應有副作用(可能被呼叫任意多次)。

• std::launch::async:函式必須在獨立的新執行緒上執行。
• std::launch::deferred:延遲到對 future 呼叫 wait()/get() 時,才在呼叫端執行緒上執行;若從未呼叫,函式可能永不執行。
• 預設 = deferred | async,由實作自行選擇。要保證真正併發必須明確指定 std::launch::async。

1. std::async:最直接——啟動非同步任務並取回傳值。
2. std::packaged_task<Sig>:將 future 綁定到可調用物件;任務可入佇列、交給執行緒池或指定執行緒(GUI 執行緒)執行,調度器只處理 packaged_task 而不管函式細節。
3. std::promise<T>:最底層——顯式 set_value()/set_exception();適合結果無法表達成單一函式呼叫、或來自多處的情況(如單執行緒處理多網路連接,封包 ID 對應 promise)。

std::future 只能移動、結果只能 get() 一次,future 物件本身不提供同步存取——多執行緒無同步地存取同一 future 會導致資料競爭與未定義行為。
正確做法:改用可拷貝的 std::shared_future(以 std::move(f)、右值隱式轉移或 f.share() 建立),並讓每個執行緒各持一份副本,各自透過自己的副本取結果即安全、無需加鎖。

• system_clock:系統實際時間(牆上時鐘),可被調整 → 不穩定;可與 time_t 互轉。
• steady_clock:節拍均勻且不可調,is_steady == true。
• high_resolution_clock:最小節拍週期(最高精度),可能是其他時鐘的 typedef。
  超時計算應使用 steady_clock:system_clock 可能被校時而使 now()「倒退」,以它為基準的等待時間會失真。

• latch:一次性——計數歸 0 即就緒並保持就緒直到銷毀;不在乎誰遞減(同一執行緒可減多次、多執行緒各減一次皆可)。
• barrier:可重複使用——每週期每個執行緒只能到達一次(arrive_and_wait),全員到齊即釋放並重置進入下一週期;arrive_and_drop 可退出組(下一週期所需人數 −1)。
• flex_barrier:額外接受一個完成函式,全員到達後由其中一個執行緒執行(串行區);其回傳值可指定下一週期的執行緒數(−1 = 不變)。

1. std::async:std::future<double> f = std::async(square_root, -1); 函式拋出的例外會存入 future,呼叫 f.get() 時重拋(packaged_task 同理)。

2. std::promise 顯式存入:

   try { p.set_value(square_root(x)); }
   catch (...) { p.set_exceptioncurrent_exception(); }
   

   若 promise/packaged_task 未設值就銷毀,future 會存入 std::future_error,錯誤碼為 std::future_errc::broken_promise。

用 wait_until + steady_clock 的固定截止時間點:

auto const timeout = std::chrono::steady_clock::now() +
                     std::chrono::milliseconds(500);
std::unique_lock<std::mutex> lk(m);
while (!done)
    if (cv.wait_until(lk, timeout) == std::cv_status::timeout)
        break;
return done;

理由:迴圈是為了處理虛假喚醒;若用 wait_for,每次虛假喚醒後重新呼叫會重置計時,可能重複多次造成等待時間無上限。wait_until 以固定時間點為準,迴圈總長有界。

• 規模:每層遞迴 async 一次,執行緒數約每層倍增——3 層約 8 條、10 層(約 1000 元素)可達 1024 條,遠超硬體併發數 → 任務超額、上下文切換開銷。
• 緩解:預設策略(deferred | async)給實作自由——任務過多時可同步/延遲執行新任務(在呼叫 get() 的執行緒上跑,避免任務傳遞開銷);明確指定 launch::async 則強制每任務一執行緒。行為依實作而異。
• spawn_task 更糟:無任何自動裁剪,必定每任務開一條執行緒 → 大規模超額;其價值在於可鋪墊成「任務入佇列 + 執行緒池」的實作(第9章)。
• 另注意 std::partition 仍是串行,是整體加速的天花板。

• async 收集版:收集任務本身佔用一條執行緒;對每個未就緒的 future 呼叫 get() 會反覆「喚醒 → 未就緒 → 再休眠」,增加上下文切換與額外開銷。
• when_all 版:回傳的新 future 在全部就緒時才觸發 .then 持續性——免輪詢、不佔用執行緒;持續性內的 f.get() 全部立即返回。
• 改用 when_any:當「任一任務完成即可繼續」時——例如多任務平行搜尋,找到任一符合值就處理;when_any_result 的 index 指出就緒者,搭配共享 std::atomic<bool> done_flag 讓其他任務提早停止;沒找到就對剩餘 futures 遞迴再掛 when_any。