std::atomic 在哪裡隱藏它的鎖?
在多元素資料結構中,標準原子類型可能並不總是鎖定 -自由的。這是由於 CPU 在沒有鎖的幫助下無法處理此類資料。為了說明這一點,請考慮以下範例:
#include <iostream> #include <atomic> struct foo { double a; double b; }; std::atomic<foo> var; int main() { std::cout << var.is_lock_free() << std::endl; std::cout << sizeof(foo) << std::endl; std::cout << sizeof(var) << std::endl; }
Linux/gcc 的輸出顯示以下:
0 16 16
假設原子類型和foo 結構佔用相同的空間量,鎖似乎不太可能儲存在原子中。但這個難題背後的真相究竟是什麼?
多個實例的鎖定位置和意義
常規方法涉及使用互斥鎖(或自旋鎖)鍵控的雜湊表到原子物件的位址。此雜湊函數傾向於將位址的最低位元作為大小為 2^n 的陣列的索引。
否則,LLVM std::atomic 實作會合併較高的位址位元以防止自動別名。這確保了由 2 的有效冪分隔的物件不會映射到同一個鎖。
重要的是,原子物件僅在不同進程之間共享記憶體時以無鎖定方式操作,其中每個進程都配備具有自己的鎖定哈希表。
雜湊表內的衝突可能需要小心。雖然這不會造成正確性問題,但它可能會因促進多個執行緒之間的爭用而損害效能。然而,這種情況相對較少發生,因為無鎖原子物件通常在相關平台上受到青睞。
關於死鎖,請放心,這不是一個問題,因為 std::atomic 函數不會取得鎖同時作用於多個物體。因此,負責取得鎖的函式庫程式碼在持有現有鎖的同時絕對不會嘗試取得額外的鎖。
以上是`std::atomic` 是否使用隱藏鎖,如果是,它位於哪裡?的詳細內容。更多資訊請關注PHP中文網其他相關文章!