线程真的很危险？

zhendehaoren

在看一本书中写道：
x=0；
thread1     thread2
lock；        lock；
x++；       x++；
unlock；    unlock；

虽然有锁的保护，但是如果编译器为了提高x的访问速度，会把x放到某个寄存器里，不同线程的寄存器各自独立，
还有种情况就是cpu乱序执行指令。即使加锁也不能保证线程安全。

但为何多线程大量被使用？


书上说解决方法有两个 volatile 和 barrier  但是说实话很少见用到过。

fender0107401

编译器优化性能不会改变程序逻辑，否则就是软件bug。

CPU乱序执行不会改变程序逻辑，否则就是硬件bug。

lz贴出书名来看看。

Dannysd

找本好书看吧~

hellioncu

这书有问题

folklore

回复 4# hellioncu


    这书没问题。。。

加volatile是对的，
禁止将变量优化到寄存器。

简化化就是这样的情况：

1. load r0,x
   
2. lock
   
3. inc r0;
   
4. store r0,y; 取全局x值。 但事实上被优化成直接使用r0了，
   
5. ulock
   
6. store r0,x

复制代码

加了volatile后是这样

1. 
   
2. lock
   
3. load r0,x
   
4. inc r0;
   
5. store r0,x
   
6. store r0,y; 取全局x值。 因为有了volatile和Lock,++不会丢失。
   
7. ulock
   

复制代码

hellioncu

folklore 发表于 2014-08-02 13:05
回复 4# hellioncu

加了锁就没事了，不必再用volatile，也无需额外的barrier。
没有锁，只用volatile是有问题的

zhendehaoren

书名是 程序员自我修养

它是windows和linux参合在一起讲的，可能说的是window下的情况

folklore

回复 6# hellioncu


    我的理解，他那个lock不是汇编的lock， 只是OS的API 或是用户态的lock。
这个lock是不会更新寄存器的， 也就是变更被“地方化”了。
volatile是用来禁止变量优化到寄存器的。
同时加volatile和lock才是逻辑上正确的，
不过大多数情况下只加lock不加volatile也没事，
但这只是“碰巧”而已，
因为CPU寄存器太少了， 就算不加volaitle，
变量也没有机会被优化成前面的情形。

csumck

同意８楼，但是volatile不能完全解决问题，尤其时现在生产环境很多是多ＣＰＵ环境．
还是要靠barrier, 不加barrier没有出错只是碰巧而已．
我曾经有个多线程的程序，线程A初始化变量x，然后线程Ｂ设置变量x，然后线程Ａ又去读取变量x，执行顺序完全没问题，但是在某些机器上线程Ａ最后读取变量x时就有机会读到一个错误的值．加了barrie就正常了．

zhendehaoren

怕的就是这种碰巧，之前写的多线程程序有时好好的就挂掉了，死活找不到原因，从逻辑上看一点问题没有，很可能就是这些细节导致的