並行 API練習題 (Practice - Concurrency API)

std::thread API 沒有直接管道取得非同步函式的回傳值；應改用 task-based 寫法 auto fut = std::async(doAsyncWork);，透過 future 的 get() 取得結果。
若 thread-based 下函式丟出例外，程式會呼叫 std::terminate 直接終止；task-based 下例外會存入 shared state，由 get() 重新拋出、可以 catch。

三種意義：hardware threads（CPU core 上真正執行運算）、software threads（OS 跨 process 管理與排程，可多於 hardware threads）、std::thread（C++ 物件，底層 software thread 的 handle，可能為 null handle——預設建構、被 move 走、已 join、已 detach）。
仍可能丟例外：software threads 是有限資源，耗盡時 std::thread 建構會丟 std::system_error——例外來自建立執行緒，與函式本身是否 noexcept 無關。

不正確。預設 launch policy 是 std::launch::async | std::launch::deferred（兩者 OR），由執行期系統決定：f 可能真正非同步執行，也可能被 deferred——延遲到對 future 呼叫 get/wait 時才在呼叫者的執行緒上同步執行；若從未呼叫 get/wait，f 永遠不會執行。
要保證真正非同步，必須明確傳入 std::asyncasync, f。

高負載（oversubscription / thread exhaustion）時，預設政策的任務最容易被排為 deferred；deferred 任務的 wait_for 永遠回傳 std::future_status::deferred，不可能等於 ready，迴圈因此永不終止。這正是測試抓不到、只在重載下現形的典型 bug。
修正：先以零逾時探測 if (fut.wait_for(0s) == std::future_status::deferred)，是 deferred 就直接對 fut 呼叫 get/wait 同步執行；否則才進入 timeout 迴圈。或一開始就指定 std::launch::async。

以下全部成立時，預設政策才安全：(1) 任務不需要與呼叫 get/wait 的執行緒併發執行；(2) 讀寫哪條執行緒的 thread_local 變數無關緊要；(3) 保證會對 future 呼叫 get/wait，或可接受任務永不執行；(4) 使用 wait_for/wait_until 的程式碼已考慮 deferred 狀態。
任一條不成立（例如 f 依賴 TLS、或必須真正併發），就明確傳 std::launch::async（或用完美轉發包裝的 reallyAsync）。

解構 joinable 的 std::thread 會使程式終止（std::terminate）——不是 UB、也不是隱式 join 或 detach。「所有路徑」包含流到 scope 結尾、return、continue、break、goto 與例外。
Unjoinable 的四種情況：預設建構、被 move 走、已 join、已 detach。注意：底層執行緒已跑完的 std::thread 仍是 joinable。

(1) 對 unjoinable 的 thread 呼叫 join()/detach() 是未定義行為——使用者可能已透過 get() 對 t 做過 join/detach/move，所以必先檢查。此檢查與後續動作之間沒有 race：joinability 只能經成員函式改變，若真有並行呼叫，race 在呼叫端。
(2) std::thread 初始化後可能立即開始執行，宣告在成員列表最後可保證它執行時，其前面的成員都已初始化、可被安全存取。
(3) 宣告解構子會抑制編譯器生成 move 操作，需以 ThreadRAII(ThreadRAII&&) = default; 與 move assignment = default 顯式要回（Item 17）。

Implicit join：解構子等待底層執行緒完成 → doWork 明明已判定不需要計算結果（conditionsAreSatisfied() 回傳 false），卻仍苦等 filter 跑完千萬筆——反直覺的效能異常，極難追查。
Implicit detach：doWork 返回後 stack frame 被回收，背景 lambda 仍繼續對「曾是 goodVals」的記憶體 push_back；後續函式 f 佔用同一段 stack 時，其 stack frame 內容會憑空改變——除錯噩夢級的未定義行為。
兩者的共同缺點是問題延遲且隱蔽地浮現；程式終止雖激烈，但後果明確、立即可見，因此被認為是「爛選項中最不爛的」。這也解釋了為何需要 RAII 類別讓程式設計者明確選擇 join 或 detach。

正常行為：只銷毀 future 的資料成員，並遞減 shared state 的參考計數——不 join、不 detach、不執行任何東西；對非同步任務等同隱含 detach，若是 deferred 任務的最後一個 future，該任務永不執行。future 解構永不導致程式終止。
唯一例外（三條件全部成立才阻塞至任務完成，等同隱含 join）：(1) shared state 來自 std::async；(2) 任務的實際 launch policy 為 std::launch::async；(3) 它是指涉該 shared state 的最後一個 future（std::shared_future 只有最後一份才阻塞）。
注意：future API 無法查詢是否來自 std::async，所以持有 future 的容器或類別解構時都「可能」阻塞。

不會阻塞：來自 std::packaged_task 的 shared state 不是 std::async 建立的，fut 必走正常解構行為。終止 / join / detach 的抉擇由操作底層 std::thread 的程式碼決定——什麼都不做則 t 在 scope 結尾仍 joinable → 程式終止；已 join 或已 detach 則 fut 解構無事可做。
std::packaged_task 不可複製，傳入 std::thread 建構子時必須以 std::move(pt) 轉為 rvalue（Item 23）。另外若打算用 std::async 執行任務，就沒必要先建 packaged_task。

純 condvar：需要多餘的 mutex（code smell）；notify 先於 wait 則通知遺失、永久等待；有 spurious wakeup（且反應任務可能無法自行驗證事件）。
輪詢 flag（while (!flag);）：無上述問題，但不是真正阻塞——佔用硬體執行緒、context switch 成本、耗電。
condvar + flag：正確但彆扭（stilted）：notify 說「可能發生」、flag 才說「確定發生」，雙重機制。
void future：免 mutex、set 先於 wait 仍正確、免疫 spurious wakeup、真正阻塞；代價是 (1) shared state 通常在 heap 配置，(2) std::promise 只能 set 一次——one-shot，不能重複使用。

因果鏈：例外使 p.set_value() 永遠不會被呼叫 → lambda 中的 wait() 永不返回 → 執行緒永不結束 → 例外離開 scope 時 ThreadRAII 解構子執行 join()，但 join 永遠等不到執行緒結束 → detect 懸掛（hang）。這比 Item 37 所說的「效能異常」更糟——join-on-destruction 與暫停執行緒併用時可能直接卡死；Meyers 將解法留作讀者習題。
多反應任務版本：以 auto sf = p.get_future().share(); 取得 std::shared_future<void>（share() 會轉移 shared state 所有權），每條反應執行緒的 lambda 必須傳值捕獲 [sf] 自己的拷貝再 sf.wait()；一次 p.set_value() 即可喚醒全部，最後逐一 join() 使所有執行緒 unjoinable。

std::atomic 是並行工具：多執行緒共享資料且不用 mutex——保證所有操作（含 RMW）的原子性，且預設 sequential consistency 禁止寫入前的程式碼被重排到其後。volatile 是特殊記憶體工具（如 memory-mapped I/O）：告訴編譯器不得優化掉 redundant loads / dead stores，對原子性與重排毫無保證。
不一定是 2：++ 是 read-modify-write 三步操作，兩執行緒可能都讀到 0、各寫回 1；且同時讀寫非 atomic 又無 mutex 保護的記憶體就是 data race → 未定義行為，結果根本不可預測。換成 std::atomic<int> 則必定是 2。兩者用途不同，甚至可合用：volatile std::atomic<int>。

auto y = x; 與 y = x; 都無法編譯：std::atomic 的 copy 建構與 copy 賦值皆被 = delete（硬體無法在單一原子操作中「讀 x 又寫 y」；move 操作也因 Item 17 的生成規則而不存在）。正確寫法：std::atomic<int> y(x.load()); 與 y.store(x.load());——但 load 與 store 是分開的呼叫，整條敘述並非單一原子操作，且編譯器可把 x.load() 存進暫存器只讀一次，故 atomic 不適合特殊記憶體。
若 x 是 volatile int：auto 推導非參考非指標型別時會丟棄 const/volatile，y 的型別是 int（對 y 的冗餘讀寫可優化，但對 x 的每次讀取都必須執行）。