鑒于以下情況：
class Foo
{
public:
void Increment()
{
_InterlockedIncrement(&m_value); // OSIncrementAtomic
}
long GetValue()
{
return m_value;
}
private:
long m_value;
};
讀取是否需要記憶體屏障m_value？我的理解是，這_InterlockedIncrement將產生一個完整的記憶體屏障，并確保在任何后續加載發生之前存盤該值。所以從這方面聽起來很安全，但是，可以m_value快取，即可以GetValue()回傳一個陳舊的值，即使是原子遞增的？
Jeff Preshing 的優秀文章供參考：https ://preshing.com/20120515/memory-reordering-caught-in-the-act/
uj5u.com熱心網友回復：
是的，障礙應該在雙方：閱讀和寫作。想象一下，您有一些寫入緩沖區和一個加載佇列，其中所有內容都可能出現故障。所以你在寫你的東西時重繪 寫緩沖區，但是你需要處理的加載佇列在另一個執行緒（處理器）上，它對你的重繪 一無所知。所以它始終是一個配對程序。
您也可以在編譯器帽子中考慮它：除非編譯器被迫序列化訪問，否則它有權重新排序它可以安全地（根據它的觀點）做的任何事情。
也就是說，這完全是關于序列化而不是原子性。這完全是另一回事。你的寫作是原子的_InterlockedIncrement，但閱讀不是原子return m_value的。所以這是一場比賽。
另外，我看到您的代碼需要原子性，但我認為不需要序列化。你不保護任何東西m_value。至于“陳舊”的價值：通常你不能保證在某個時間點你不會有陳舊的價值，即使有障礙。RMW 操作需要最新的值，但其他操作不需要。因此，設定障礙將有助于更快地獲得最新值，但僅此而已。有了你的代碼而忘記了比賽，編譯器可能會安全地假設你沒有修改m_value和快取它。CPU 也可以這樣說。
所有這一切：只std::atomic在需要不受保護的變數時使用。它將確保該值不被任何物體快取。
uj5u.com熱心網友回復：
簡短的回答：是的。
您的“閱讀”應該具有“獲取”順序，因此Increment()當它在增量網路之后執行“釋放”時，您的結果將在另一個執行緒中可見。
uj5u.com熱心網友回復：
不，你不需要障礙，但是如果讀者和作者在不同的執行緒中呼叫這些函式，你的代碼無論如何都會被破壞。特別是如果讀者在回圈中呼叫 read 函式。
TL:DR：在增量和閱讀器中std::atomic<long> m_value使用C 11。這將在無資料競爭的程式中為您提供順序一致性：執行將像執行緒以某種源順序交錯運行一樣作業。（除非您違反規則并擁有其他非共享資料。） m_valuereturn m_valueatomic
如果您不需要與讀取器/寫入器在同一執行緒中對其他return m_value.load(std::memory_order_acquire)物件的操作進行如此強的排序，那么對于大多數用途來說就足夠了，并且m_value.fetch_add(1, std::memory_order_acq_rel). 很少有程式在任何地方都需要 StoreLoad 屏障；即使使用 .atomic RMWs 實際上也無法重新排序acq_rel。（在 x86 上，它們的編譯方式與您使用的一樣seq_cst。）
您不能強制在執行緒之間進行排序；負載要么看到該值，要么沒有，這取決于讀取執行緒是在它獲取/嘗試獲取負載值之前還是之后看到來自寫入器的無效。執行緒的全部意義在于它們不會彼此同步運行。
資料競賽 UB：
回圈讀數m_value可以將負載提升到回圈之外，因為它不是atomic（甚至volatile作為黑客）。這是資料競賽 UB，編譯器會破壞你的閱讀器。看到這個和多執行緒程式卡在優化模式但在 -O0 中正常運行
障礙不是這里的問題/解決方案，只是強制重新檢查記憶體（或當前 CPU 看到的記憶體的快取一致視圖；像 L1d 和 L2 這樣的實際 CPU 快取對此沒有問題）。這不是障礙的真正作用。他們命令該執行緒訪問一致的快取。C 執行緒僅在具有一致快取的內核上運行。
但是，如果沒有非常令人信服的理由， 請認真不要推出自己的原子。何時在多執行緒中使用 volatile？幾乎從來沒有。該答案解釋了快取一致性，并且您不需要障礙來避免看到陳舊的值。
在許多現實世界的 C 實作中，類似的東西std::atomic_thread_fence()也將是一個“編譯器屏障”，它強制編譯器從記憶體中重新加載非原子變數，即使沒有volatile，但這是一個實作細節。因此，在某些 ISA 的某些編譯器上，它可能恰好作業得很好。并且對于編譯器發明多個負載仍然不是完全安全的；請參閱 LWN 文章誰害怕一個糟糕的優化編譯器？有關詳細資訊的示例；主要針對 Linux 內核如何使用volatileGCC/clang 實際上支持它自己的原子。
“最新值”
初學者經常對此感到恐慌，并認為 RMW 操作在某種程度上更好，因為它們被指定的方式。由于它們是讀 寫系結在一起的，并且每個記憶體位置都有一個修改順序， RMW 操作必須等待對高速快取行的寫訪問，這意味著在單個位置上序列化所有寫和 RMW。
仍然可以保證（通過實際實作）大量加載原子變數以迅速查看值。
See MESI Protocol & std::atomic - Does it ensure all writes are immediately visible to other threads?. Other answers incorrectly suggest that memory barriers make data visible faster, but that's not really true, except for minor secondary effects: see my comments on https://github.com/dotnet/runtime/issues/67330#issuecomment-1083539281 and Does hardware memory barrier make visibility of atomic operations faster in addition to providing necessary guarantees? No, it doesn't.
Certainly not enough to be worth slowing down the reader with lots of extra barriers just to make it look at this atomic variable later than other atomic variables, if you didn't need that ordering for correctness.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/455498.html
上一篇：HO引擎近況20220403
下一篇：Vulnhub 之 Earth