共享資料練習題 (Practice - Sharing Data)

競爭條件泛指結果取決於多執行緒執行的相對順序;不變量未被破壞者為良性(如兩執行緒同時往佇列加任務),可以接受。資料競爭 (data race) 是 C++ 標準術語,指未同步地並發修改同一物件,直接導致未定義行為。惡性競爭需要 CPU 指令序恰好交錯才觸發,出現機率低、對時間敏感——除錯模式改變了程式的執行時序,所以 bug 常常「消失」;系統負載增加時反而更易復現。

手動呼叫必須在每個函式出口(含例外路徑)配對 unlocklock_guard 以 RAII 在建構時上鎖、解構時解鎖,例外時也保證釋放。即使全部上鎖,只要成員函式把受保護資料的指標或引用傳出鎖的作用域(回傳值、輸出參數、或傳給使用者提供的函式,呼叫端就能在無鎖狀態下存取資料。準則:切勿將受保護資料的指標或引用傳遞到互斥鎖作用域之外。

1. empty→top 競爭:①②之間另一執行緒可能 pop() 掉最後一個元素,對空堆疊呼叫 top() 是未定義行為。
2. top→pop 競爭:兩執行緒交錯執行時可能同一值被處理兩次、另一值被丟棄從未處理——看似無錯,更難定位。

這是介面設計本身的問題(檢查與取值/移除被拆成多個呼叫),與實作方式無關,無鎖實作同樣中招;必須重新設計介面,把操作合併在同一把鎖內(如 threadsafe_stack 的 pop 同時完成檢查+取值+移除)。

std::adopt_lock 告訴 lock_guard:mutex 已被上鎖,只需接管、負責解構時解鎖,不要再上鎖。std::lock 具全有或全無語義——鎖第二個 mutex 時若拋例外,第一個會自動釋放,不會留下半鎖狀態(內部以 try_lock() 作為避免死結演算法的一部分)。C++17 可用一行 std::scoped_lock guard(lhs.m, rhs.m);(可變參數 RAII + CTAD)取代整組樣板。

DCLP 的第一次無鎖讀取指標與上鎖後的寫入之間沒有同步,是資料競爭 → 未定義行為;競爭不只在指標,還包括指標指向的物件——執行緒可能看到指標非空,卻看不到新建物件的完整內容。正解:

1. std::call_once + std::once_flag:保證初始化恰好完整執行一次,開銷比顯式鎖低;可傳成員函式 + this 做類別成員的延遲初始化。
2. C++11 static 區域變數:標準保證初始化只發生在一個執行緒中,其他執行緒等它完成——單例的最簡解法。

注意:std::mutex 與 std::once_flag 不可複製、不可移動。

用讀寫鎖:讀者以 std::shared_lock<std::shared_mutex> 取得共享鎖(多執行緒可同時持有);寫者以 std::lock_guard<std::shared_mutex> 或 std::unique_lock<std::shared_mutex> 取得獨占鎖。互斥規則:有人持共享鎖時,想拿獨占鎖者阻塞至全部釋放;有人持獨占鎖時,誰都拿不到任何鎖。版本:C++11 無(用 Boost)、C++14 只有 std::shared_timed_mutex、C++17 新增 std::shared_mutex(操作較少、效能較佳)。效能仍取決於處理器數與讀寫負載比,需實測。

違反層級規則——已持 6000 卻想鎖更高的 10000,check_for_hierarchy_violation() 立即拋出例外(或終止程式)。關鍵機制:static thread_local 變數記錄當前執行緒的層級(初始 ULONG_MAX,故第一把鎖必能上),只允許獲取層級更低的鎖;解鎖須依相反順序並恢復前值。優點:執行期偵測、無時間依賴——不必等死結真的發生,即使當下無競爭也會報錯。因為它提供 lock()/unlock()/try_lock() 三件套,滿足 mutex 介面要求,可直接用於 std::lock_guard<hierarchical_mutex>。

std::unique_lock 支援手動 lock()/unlock(),可在不需共享資料的區段中途放鎖,把持鎖時間縮到最短:

std::unique_lock<std::mutex> my_lock(the_mutex);
some_class data = get_next_data_chunk();
my_lock.unlock();                // process() 不碰共享資料,不持鎖
result_type result = process(data);
my_lock.lock();                  // 寫回前再上鎖
write_result(data, result);

原則:持鎖時間盡可能短,耗時操作(尤其檔案 I/O,比記憶體慢成百上千倍)絕不在持鎖時做。unique_lock 內部以旗標記錄是否擁有 mutex(owns_lock() 可查),代價是比 lock_guard 佔空間、稍慢——夠用就選 lock_guard/scoped_lock。

分開是為了例外安全(Cargill 問題):若 pop() 直接回傳值,stack<vector<int>> 複製回傳值時可能拋 std::bad_alloc——值已移出堆疊、複製卻失敗,資料永久遺失。但這個分割正是介面競爭的元兇。合併後的化解:

• 選項 1 pop(T&):賦值在移除前完成,失敗不丟資料;代價是需先建構實例、型別必須可賦值。
• 選項 2(要求不拋例外的複製/移動建構):以 std::is_nothrow_*_constructible 檢查;限制太強,許多自訂型別不合格。
• 選項 3 shared_ptr<T> pop():先 make_shared 建好回傳值、最後才 data.pop(),複製指標不拋例外;代價是記憶體配置開銷(對 int 等簡單型別划不來)。
• 採 1+3 提供多載讓使用者選,並削減介面(無 top()、無 swap()、刪除賦值)——檢查與彈出全在同一把鎖內完成,介面競爭與例外安全同時解決。

std::recursive_mutex 允許同一執行緒多次上鎖(lock() 三次就要 unlock() 三次),表面上「能跑」,但通常是設計壞味道:A 呼叫 B 時,類別的不變量可能正處於被破壞的中間狀態,B 卻照常執行——鎖給的安全感是假的,B 依賴的前提可能根本不成立。

較好的做法:抽出一個不上鎖的私有成員函式承載共同邏輯(約定:呼叫前必須已持鎖),A、B 各自上鎖後呼叫它,並明確思考呼叫當下資料的狀態。這讓「誰持鎖、資料處於什麼狀態」在設計上一目瞭然,而不是靠 recursive_mutex 掩蓋問題。