这个问题是出自"程式设计师的自我修养"这一本书
里面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