线程真的很危险？

zhendehaoren

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

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

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


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

爻易

看这段代码应该是作者特意构建出来以说明问题的，这无可厚非。

只是变量并未严格置于锁的保护之下，在获得锁之前，程序就已经开始访问变量了。

因为这个原因，所以必须另外加上关键字保护。但如果所有读写变量的操作都放在获得锁之后的话，就无须关键字保护。

yaofei

volatile 不能少

zhouzhenghui

不理解的可以参考一片论文大意是：为什么线程不能由库实现

zhaohongjian000

写编译器/库的人不是傻子，该考虑的情况人家都考虑了。

锁本身就有内存屏障的语义，所以不用使用者考虑cache以及CPU乱序的问题。

编译器做优化时，不会用寄存器缓存一个全局变量并跨过一次函数调用。对于C语言/C++，
每个序列点都会把对全局变量的修改写回内存，所以不用使用者考虑编译器优化会打破锁的效果。

zylthinking

folklore 发表于 2014-08-02 13:38
回复 6# hellioncu

所有的锁， 基本上归结到用 cpu 锁 + 屏障 实现它自己的语意， 因此， 除非这个锁不合格， 否则不会有问题

smallbox120

这个问题我看了很震惊，像TLPI这些书上根本没提到这样的情况。
看来不少人对这个问题都不陌生，大家看的都是些什么书啊？

giantchen

回复 21# zhendehaoren


    书上写的是错的，不用担心这个问题，除非你用的编译器太老。

井蛙夏虫

对于遵循posix标准的线程没有问题，别的不知道。
posix规定pthread_mutex_lock和pthread_mutex_unlock必须做内存同步，除了以下的情况:

1. The pthread_mutex_lock() function need not synchronize memory if the mutex type if PTHREAD_MUTEX_RECURSIVE and the calling thread already owns the mutex. The pthread_mutex_unlock() function need not synchronize memory if the mutex type is PTHREAD_MUTEX_RECURSIVE and the mutex has a lock count greater than one.

复制代码

zhendehaoren

三爷，。。。  我不说了