根據這個重新排序規則
重新排序規則
如果我有這樣的代碼
volatile int a = 0;
boolean b = false;
foo1(){ a= 10; b = true;}
foo2(){if(b) {assert a==10;}}
讓執行緒 A 運行 foo1 和執行緒 b 運行 foo2，因為 a= 10 是一個 volatile 存盤而 b = true 是一個普通存盤，那么這兩個陳述句可能會被重新排序，這意味著在執行緒 B 中可能有 b = true 而a!=10？那是對的嗎？
添加：
感謝您的回答！
我剛剛開始學習 Java 多執行緒，并且經常被關鍵字 volatile 所困擾。
許多教程都在討論 volatile 欄位的可見性，就像“在對它的寫操作完成后，所有讀者（特別是其他執行緒）都可以看到 volatile 欄位”。我懷疑其他執行緒（或 CPU）如何看不到完整的欄位寫入？
據我了解，完成寫入意味著您已成功將檔案寫回快取，并且根據 MESI，如果該檔案已被他們快取，則所有其他執行緒都應具有無效快取行。一個例外（因為我對硬核不是很熟悉，所以這只是一個猜測）是結果可能會寫回暫存器而不是快取，我不知道在這種情況下是否有一些協議來保持一致性或 volatile 使它不寫入在 java 中注冊。
在某些看起來像“隱形”的情況下會發生示例：
A=0,B=0;
thread1{A=1; B=2;}
thread2{if(B==2) {A may be 0 here}}
假設編譯器沒有對它重新排序，我們在thread2中看到的原因是存盤緩沖區，我認為存盤緩沖區中的寫入操作并不意味著寫入完成。由于存盤緩沖區和使佇列無效的策略，這使得對變數 A 的寫入看起來不可見，但實際上寫入操作尚未完成，而執行緒 2 讀取 A。即使我們使欄位 B 易失，而我們將欄位 B 上的寫入操作設定為帶有記憶體屏障的存盤緩沖區，執行緒 2 可以讀取帶有 0 的 b 值并完成。對我來說， volatile 看起來與它宣告的檔案的可見性無關，
順便說一句，由于我不是母語人士，我看到可能使用我的母語的教程（還有一些英文教程）說 volatile 會指示 JVM 執行緒從主記憶體讀取 volatile 變數的值，并且不在本地快取它，我不認為這是真的。我對嗎？
不管怎樣，謝謝你的回答，因為不是母語人士，我希望我表達清楚。
uj5u.com熱心網友回復：
我很確定斷言可以觸發。我認為易失性負載只是獲取操作（https://preshing.com/20120913/acquire-and-release-semantics/）wrt。非易失性變數，所以沒有什么能阻止加載-加載重新排序。
兩個volatile操作不能相互重新排序，但是可以在一個方向上使用非原子操作重新排序，并且您選擇了沒有保證的方向。
（注意，我不是 Java 專家；有可能但不太可能volatile有一些需要更昂貴實作的語意。）
更具體的推理是，如果斷言在轉換為某些特定體系結構的 asm 時可以觸發，則必須允許 Java 記憶體模型觸發。
Javavolatile是（AFAIK）等效于 C std::atomic的默認memory_order_seq_cst. 因此，foo2可以為 ARM64 進行 JIT 編譯，使用普通加載 forb和 LDAR 獲取加載a。
ldar不能在以后加載/存盤時重新排序，但可以在更早的時候重新排序。（除stlr釋放存盤; ARM64被專門設計，使C std::atomic<>與memory_order_seq_cst/ Java的volatile高效與ldar和stlr，不具有沖洗店立即緩沖器上seq_cst存盤，僅在看到一個LDAR，使得設計賦予訂貨必要仍的最小量恢復 C 指定的順序一致性（我假設是 Java）。
在許多其他 ISA 上，順序一致性存盤確實需要等待存盤緩沖區自行耗盡，因此它們實際上是有序的。后來的非原子負載。再次在許多 ISA 上，獲取或 SC 負載是通過正常負載完成的，然后是一個屏障，該屏障阻止負載在任一方向穿過它，否則它們將無法作業。這就是為什么將a編譯的易失性加載到只執行獲取操作的獲取加載指令是理解這在實踐中如何發生的關鍵。
（在 x86 asm 中，所有加載都是獲取加載，所有存盤都是釋放存盤。雖然不是順序釋放；x86 的記憶體模型是程式順序 帶有存盤轉發的存盤緩沖區，這允許 StoreLoad 重新排序，因此 Javavolatile存盤需要特殊的 asm。
因此，斷言不能在 x86 上觸發，除非通過對 assignments 的編譯/JIT 時間重新排序。 這是測驗無鎖代碼之所以困難的一個很好的例子：失敗的測驗可以證明存在問題，但在某些硬體/軟體組合上的測驗無法證明正確性。）
uj5u.com熱心網友回復：
除了 Peter Cordes 的出色回答之外，就 JMM 而言，b 上存在資料競爭，因為 b 的寫入和 b 的讀取之間的邊緣之前沒有發生，因為它是一個普通變數。只有在邊緣存在之前發生這種情況，然后才能保證如果 b=1 的負載也看到 a=1 的負載。
你需要讓 b 變得不穩定，而不是讓 a 變得不穩定。
int a=0;
volatile int b=0;
thread1(){
a=1
b=1
}
thread2(){
if(b==1) assert a==1;
}
因此，如果執行緒 2 看到 b=1，那么在發生之前的順序（易失性變數規則）中，此讀取將在寫入 b=1 之前進行排序。并且由于 a=1 和 b=1 是有序發生在順序之前（程式順序規則），并且 b 的讀取和 a 的讀取在發生在順序之前（再次程式順序規則）中進行排序，那么由于發生在關系之前，在 a=1 的寫入和 a 的讀取之間有一個發生在邊緣之前；這需要看到值 1。
您指的是使用圍欄的 JMM 的可能實作。雖然它提供了一些關于引擎蓋下發生的事情的見解，但從圍欄的角度思考同樣具有破壞性，因為它們不是一個合適的心理模型。請參閱以下計數器示例：
https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#myth-barriers-are-sane
uj5u.com熱心網友回復：
是的，斷言可能會失敗。
volatile int a = 0;
boolean b = false;
foo1(){ a= 10; b = true;}
foo2(){if(b) {assert a==10;}}
JMM 保證對volatile欄位的寫入發生在從它們讀取之前。在您的示例中，任何執行緒 a 之前所做的a = 10都將發生在讀取 a 之后（執行時assert a == 10）執行緒 b 所做的任何事情之前。由于b = true在a = 10for 執行緒 a之后執行（對于單個執行緒，happens-before始終保持），因此不能保證會有排序保證。但是，請考慮：
int a = 0;
volatile boolean b = false;
foo1(){ a= 10; b = true;}
foo2(){if(b) {assert a==10;}}
在這個例子中，情況是：
a = 10 ---> b = true---|
|
| (happens-before due to volatile's semantics)
|
|---> if(b) ---> assert a == 10
由于您有一個總訂單，所以斷言保證通過。
uj5u.com熱心網友回復：
回答你的補充。
許多教程都在討論 volatile 欄位的可見性，就像“在對它的寫操作完成后，所有讀者（特別是其他執行緒）都可以看到 volatile 欄位”。我懷疑其他執行緒（或 CPU）如何看不到完整的欄位寫入？
編譯器可能會弄亂代碼。
例如
boolean stop;
void run(){
while(!stop)println();
}
第一次優化
void run(){
boolean r1=stop;
while(!r1)println();
}
第二次優化
void run(){
boolean r1=stop;
if(!r1)return;
while(true) println();
}
所以現在很明顯這個回圈永遠不會停止，因為實際上永遠不會看到要停止的新值。對于商店，你可以做一些類似的事情，可以無限期地推遲它。
據我了解，完成寫入意味著您已成功將檔案寫回快取，并且根據 MESI，如果該檔案已被他們快取，則所有其他執行緒都應具有無效快取行。
正確的。這通常稱為“全域可見”或“全域執行”。
一個例外（因為我對硬核不是很熟悉，所以這只是一個猜測）是結果可能會寫回暫存器而不是快取，我不知道在這種情況下是否有一些協議來保持一致性或 volatile 使它不寫入在 java 中注冊。
所有現代處理器都是加載/存盤架構（甚至是 uops 轉換后的 X86），這意味著存在顯式加載和存盤指令，可以在暫存器和記憶體之間傳輸資料，而像 add/sub 這樣的常規指令只能與暫存器一起使用。所以無論如何都需要使用暫存器。關鍵部分是編譯器應該尊重源代碼的加載/存盤并限制優化。
假設編譯器沒有對它重新排序，我們在thread2中看到的原因是存盤緩沖區，我認為存盤緩沖區中的寫入操作并不意味著寫入完成。由于存盤緩沖區和使佇列無效的策略，這使得對變數 A 的寫入看起來不可見，但實際上在執行緒 2 讀取 A 時寫入操作尚未完成。
在 X86 上，存盤緩沖區中的存盤順序與程式順序一致，并將按程式順序提交到快取。但是在某些架構中，存盤緩沖區中的存盤可以無序提交到快取，例如由于：
寫合并
允許存盤在快取行以正確狀態回傳時立即提交快取，無論較早的是否仍在等待。
與 CPU 的子集共享存盤緩沖區。
Store buffers can be a source of reordering; but also out of order and speculative execution can be a source.
Apart from the stores, reordering loads can also lead to observing stores out of order. On the X86 loads can't be reordered, but on the ARM it is allowed. And of course the JIT can mess things up as well.
Even we make field B volatile, while we set a write operation on field B to the store buffer with memory barriers, thread 2 can read the b value with 0 and finish.
It is important to realize that the JMM is based on sequential consistency; so even though it is a relaxed memory model (separation of plain loads and stores vs synchronization actions like volatile load/store lock/unlock) if a program has no data races, it will only produce sequential consistent executions. For sequential consistency the real time order doesn't need to be respected. So it is perfectly fine for a load/store to be skewed as long as:
there memory order is a total order over all loads/stores
the memory order is consistent with the program order
a load sees the most recent write before it in the memory order.
As for me, the volatile looks like is not about the visibility of the filed it declared, but more like an edge to make sure that all the writes happens before volatile field write in ThreadA is visible to all operations after volatile field read( volatile read happens after volatile field write in ThreadA has completed ) in another ThreadB.
You are on the right path.
Example.
int a=0
volatile int b=;
thread1(){
1:a=1
2:b=1
}
thread2(){
3:r1=b
4:r2=a
}
In this case there is a happens before edge between 1-2 (program order). If r1=1, then there is happens before edge between 2-3 (volatile variable) and a happens before edge between 3-4 (program order).
Because the happens before relation is transitive, there is a happens before edge between 1-4. So r2 must be 1.
volatile takes care of the following:
Visibility: needs to make sure the load/store doesn't get optimized out.
That is load/store is atomic. So a load/store should not be seen partially.
And most importantly, it needs to make sure that the order between 1-2 and 3-4 is preserved.
By the way, since I am not an native speakers, I have seen may tutorials with my mother language(also some English tutorials) say that volatile will instruct JVM threads to read the value of volatile variable from main memory and do not cache it locally, and I do not think that is true.
You are completely right. This is a very common misconception. Caches are the source of truth since they are always coherent. If every write needs to go to main memory, programs would become extremely slow. Memory is just a spill bucket for whatever doesn't fit in cache and can be completely incoherent with the cache. Plain/volatile loads/stores are stored in the cache. It is possible to bypass the cache for special situations like MMIO or when using e.g. SIMD instructions but it isn't relevant for these examples.
Anyway, Thanks for your answers, since not a native speakers, I hope I have made my expression clearly.
Most people here are not a native speaker (I'm certainly not). Your English is good enough and you show a lot of promise.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/318746.html
上一篇：獨立多執行緒和共享資料問題
下一篇：并發編程練習