洗掉物件后未完成的存盤會發生什么？

考慮以下簡單函式（假設大多數編譯器優化已關閉）由具有存盤緩沖區的 X86 CPU 上不同內核上的兩個執行緒執行：

struct ABC
{
  int x;
  //other members.
};
void dummy(int index)
{
  while(true)
  {
    auto abc = new ABC;
    abc->x = index;
    cout << abc->x;
    // do some other things.
    delete abc;
  }
}

這里，index 是執行緒的索引；1 由 thread1 傳遞，2 由 thread2 傳遞。因此，thread1 應始終列印 1，thread2 應始終列印 2。

會不會有將store to x放到store buffer中，delete執行后commit的情況？或者是否有一個隱式記憶體屏障確保在洗掉之前提交存盤？還是一旦遇到洗掉，任何未完成的商店都會被丟棄？

這變得重要的情況：

由于 delete 將物件的記憶體回傳到空閑串列（使用 libc），因此執行緒 1 中剛剛釋放的一塊記憶體可能由執行緒 2 中的 new 運算子回傳（不僅是虛擬地址，甚至回傳的底層物理地址可以相同）。如果未完成的存盤可以在洗掉后執行，則可能在執行緒 2 將 abc->x 設定為 2 后，執行緒 1 中的一些較舊的未完成存盤將其覆寫為 1。

這意味著在上面的程式中，thread2 可以列印 1，這是絕對錯誤的。執行緒 1 和執行緒 2 是完全獨立的，從程式員的角度來看，執行緒之間沒有資料共享，他們不必擔心任何同步。

我在這里想念什么？

uj5u.com熱心網友回復：

在一個執行緒內

CPU 必須為單個執行緒保留按程式順序一次執行一條指令的錯覺。這是 OoO exec 的基本規則。 這意味著跟蹤程式順序是什么，并確保加載始終看到與其一致的值，并且最終寫入快取的值也是一致的。

這很像 C 的“as-if”規則，只是需要保留不同的 observables。（與 CPU ISA 不同，C 對合法允許觀察的其他執行緒的內容非常嚴格，但編譯時和運行時記憶體重新排序都不能通過重新排序源代碼行¹來解釋）

由該核心加載監聽存盤緩沖區，如果加載正在重新加載尚未提交的存盤，則從其中轉發資料。

對于任何單獨的記憶體位置，確保其修改順序與程式順序相匹配，即不將存盤重新排序到同一位置。所以塵埃落定后的最終值是程式順序中的最后一個。甚至其他執行緒的觀察也會看到該位置的一致修改順序；這就是為什么std::atomic能夠保證每個物件分別存在一個修改順序，如果程式順序存盤 B 然后 A，則不對 A 然后 B 然后回傳 A 進行額外更改。ISO C 可以保證這一點，因為所有現實世界的 CPU 也保證。

像這樣的系統呼叫munmap是一種特殊情況，但除此之外new/ delete（和malloc/ free）就 CPU 而言并不特殊：在空閑串列中放置一個塊并讓其他代碼分配它只是另一種搞亂指標的情況- 基于資料結構。與往常一樣，CPU 會跟蹤其所做的任何重新排序，以確保負載看到正確的值。

被另一個執行緒重用

擔心這一點并沒有錯；僅基于 CPU 架構，正確性不會在這里免費發生；一個有問題的 libc 可能會出錯并完全允許您描述的問題。 @ixSci 的回答參考了 C 標準的相關部分。（記憶體訪問的編譯時順序。呼叫 new/delete 也是必要的，但是對于編譯器不知道是“純”的任何非行內函式呼叫，總是必須發生這種情況；任何函式都可能讀取或寫入記憶體，所以它必須是同步的。）

如果記憶體被放置在可以被另一個執行緒重用的全域空閑串列中，執行緒安全分配器將使用足夠的同步來創建 C 發生之前的關系，之前使用的代碼隨后洗掉了記憶體，與剛剛分配它的另一個執行緒中的代碼。

因此，任何舊執行緒存盤到這個記憶體塊中，對于剛剛分配記憶體的執行緒都是可見的。所以他們不會踩到它的商店。如果新執行緒將指向該記憶體的指標傳遞給第三個執行緒，它最好使用 acq/rel 或使用/釋放同步本身來確保第三個執行緒看到它的存盤，而不是仍然從第一個執行緒存盤。

完全取消映射，以便訪問該虛擬地址錯誤

如果free涉及munmap使用syscall指令運行更改頁表的內核代碼（使映射無效，因此加載/存盤到它會出錯），它本身將提供足夠的序列化。現有的 CPU 不會重命名特權級別，因此它們不會通過 syscall 指令對內核進行亂序執行。

盡管在 x86-64invlpg上已經是一個序列化指令，但作業系統可以在修改頁表時做足夠的記憶體限制。（在 x86 術語中，這意味著耗盡 ROB 和存盤緩沖區，因此所有先前的指令都已完全執行，并將其結果寫回 L1d 快取（用于存盤）。）因此，它不可能重新排序依賴于較早的加載/存盤在那個 TLB 條目上，即使除了切換到內核模式。

（不過，切換到內核模式并不一定會耗盡存盤緩沖區；這些存盤的物理地址是已知的。TLB 檢查是在執行存盤地址微指令時完成的。因此對頁表的更改不會影響將它們記入記憶的程序。）

Footnote 1: memory reordering isn't source reordering

BTW, memory reordering doesn't work like reordering statements in the C source or instructions in the asm machine code; memory reordering is about what other threads can observe as loads read from cache and stores eventually commit to cache at the far end of the store buffer. Reordering the source to try to explain this break the code, violating the as-if rule, but memory-reordering can produce such effects while still having the thread's operations see correct values for its own stores, e.g. by store-forwarding. That's because real-world ISAs don't have sequentially consistent memory models; you need extra ordering to recover SC. Even an in-order CPU pipeline can reorder loads with a cache that can hit-under-miss, for example, and even strongly-ordered x86 allows StoreLoad reordering: its memory model is basically program-order plus a store buffer with store-forwarding.

(There was discussion in comments about compile-time reordering and source ordering; the question didn't have this misconception.)

The C as-if rule is the same idea that CPUs follow as they execute, just that the ISA's rules are what govern the requirements on external observables. No ISA has memory-ordering rules as weak as ISO C , e.g. they all guarantee a coherent shared cache, and many CPU ISAs don't have UB. (Although some do, e.g. calling it "unpredictable" behaviour. Much more often just an unpredictable or undefined result in some register; user/supervisor privilege separation requires there be limits on what behaviour is possible so user-space can't run some unsupported instruction sequence and maybe take over or crash the whole machine.)

Fun fact: on strongly-ordered x86 specifically, store and load ordering need to be more closely tied together than most ISAs; Intel calls the combination of store buffer load buffer the Memory Order Buffer, because it also has to detect cases where a load took a value early, before it was architecturally allowed to (LoadLoad ordering), but then it turns out this core lost access to the cache line. Or in case of mis-speculation about store-forwarding, e.g. dynamically predicting that a load would be reloading a store from an unknown address, but then it turns out the store was non-overlapping. In either case, the CPU rewinds the out-of-order back-end back to a consistent retirement state. (This is called a pipeline nuke; this specific cause is counted by the machine_clears.memory_ordering perf event.)

uj5u.com熱心網友回復：

根據 C 20 (new.delete.dataraces/p1) 我們有以下保證：

對分配或解除分配特定存盤單元的這些函式的呼叫應以單個總順序發生，并且每個此類解除分配呼叫應在（6.9.2）此順序的下一次分配（如果有）之前發生。

由于每個都delete 發生在任何new相同的記憶體之前，因此在這些運算子之前排序的內容也發生在這些其他呼叫之前。并以您的示例為例：

abc->x = index;被排序在delete abc;which 發生 beforeauto abc = new ABC;和及物abc->x = index;地發生 before 之前auto abc = new ABC;。這保證了abc->x = index;之前 是完整的auto abc = new ABC;。

標籤：C 多线程 x86 cpu架构 记忆障碍

上一篇：信號量的多執行緒問題

下一篇：一個執行緒中有多個鎖，為什么需要它們？[復制]