這個問題是出自"程式設計師的自我修養"這一本書
裡面28頁陳述了一個問題
x = 0;
Thread1 Thread2
lock(); lock();
x++; x++;
unlock(); unlock();
書上說可能thread1做完x++時，這個x=1的值還留在register中還沒寫回，
之後換thread2跑完，很久之後thread1才把此值寫回，最後x的值是1
但書上這個例子看起來就是一般multithread用mutex鎖住一段code的寫法，
目前也沒看過這種寫法發生錯誤
請問這個情況什麼時候會發生？
還是說平常在用的unlock會自動把register中的值flush出去？
我把28頁照片放上來
https://photos.app.goo.gl/QYG5LffdJLUC9PfA8
(特別查了一下著作權法，放個一頁應該是沒什麼問題@@)
著作權法第五十二條規定：「
為報導、評論、教學、研究或其他正當目的之必要，在合理範圍內，
得引用已公開發表之著作。」
看不太懂,x應該是同一塊記憶體,怎會有flush的問題
作者:
Lipraxde (Lipraxde)
2018-10-14 20:14:00恩...應該 compiler 優化有問題才會像你說的這樣啊？有沒有前後文？
作者:
descent (「雄辯是銀，沉默是金」)
2018-10-14 20:30:00他後面有提到 volatile 和 memory barrier, page 29
我說flush是指寫出去到memory的意思29頁那個cpu自行換序的問題 我試過真的會發生但28頁這個我沒遇過再看一次 好像真的如同L大說的 這段是在講compiler的問題 所以compiler看到mutex夾住的要小心 應該是這意思@@我原本以為它是說code有問題 冏XD
如果是留在暫存器中,也不能算做完x++吧書上意指lock前就把x值存進暫存器?唉,連記憶體到CPU暫存器的時間也要省
作者:
PkmX (阿貓)
2018-10-15 02:18:00現在的C/C++有規範不同thread之間的memory model以std::mutex來說 unlock "synchronizes-with"下一個lockunlock前的side effects必須讓lock後的code看到如果編譯器沒有把x的值寫回記憶體的話就是做錯了
c++ 11以後要follow sequential consistency.
作者:
PkmX (阿貓)
2018-10-16 09:44:00seq_cst是atomic operation之間預設才有像上面那種bool isStop兩個threads同時寫還是UB除非你有用mutex等東西讓兩個讀寫有"happens-before"的關係
作者:
jun0325 (俊)
2018-10-16 22:12:00用volatile應該就會讓compiler每次都會寫回memory了吧
作者:
PkmX (阿貓)
2018-10-17 10:47:00照標準volatile和thread之間的synchronization是沒有關係的而且volatile也不一定是atomic access