《程序员的自我修养》中关于加锁不能保证线程安全的一个错误
2012-11-30 10:47
225 查看
《程序员的自我修养》中关于加锁不能保证线程安全的一个错误
AuthorGuanchengPublished on04/09/2011
Categories并行编程
21
Tagsmemory
visibility, Pthreads, 原子操作, 多线程编程, 线程安全
在《程序员的自我修养 — 链接装载与库》一书第28页“过度优化”这一节中,作者提到了编译器优化可能造成多线程bug的情况(我手中的是09年6月第二次印刷那版)。原文如下:
线程安全是一个非常烫手的山芋,因为即使合理的使用了锁,也不一定能保证线程安全,这是源于落后的编译器技术已经无法满足日益增长的并发需求。很多看似无错的代码在优化和并发前又产生了麻烦。最简单的例子,让我们看看如下代码:
x = 0;
Thread 1 Thread 2
lock(); lock();
x++; x++;
unlock(); unlock();
由于有lock和unlock的保护,x++的行为不会被并发所破坏,那么x的值似乎必然是2了。然后,如果编译器为了提高x的访问速度,把x放到了某个寄存器里,那么我们知道不同线程的寄存器是各自独立的,因此如果Thread 1先获得锁,则程序的执行可能会呈现如下的执行情况:
*1 Thread 1:读取x的值到某个寄存器R[1] (R[1]=0)
*2 Thread 1:R[1]++
*3 Thread 2:读取x的值到某个寄存器R[2] (R[2]=0)
*4 Thread 2:R[2]++
*5 Thread 2:将R[2]写回至x(x=1)
*6 Thread 1:(很久以后)将R[1]写回至x(x=1)
可见在这样的情况下即使正确的加锁,也不能保证多线程安全。
这个“加锁后仍不能保证线程安全”的结论其实是错误的。在对一段代码进行加锁操作之后,被锁保护起来的代码就形成了一个临界区,在任何时刻最多只能有一个线程运行这个临界区中的代码,而其他的线程必须等待(例如pthread_mutex_lock是阻塞型等待,pthread_spin_lock是忙等待)。给临界区加锁之后相当于给临界区内的代码添加了原子性的语义。
既然加锁之后临界区内的代码是原子操作的,那么就不可能出现《程》中描述的那种执行顺序,因为Thread 2必须要等到Thread 1执行完x++和unlock()之后才能获得锁并随即进行x++操作。即如下所述的执行顺序:
*1 Thread 1:lock()
*2 Thread 1:读取x的值到某个寄存器R[1] (R[1]=0)
*3 Thread 1:R[1]++
*4 Thread 1:将R[1]写回至x(x=1)
*5 Thread 1:unlock()
*6 Thread 2:lock() //得到锁
*7 Thread 2:读取x的值到某个寄存器R[2] (R[2]=1)
*8 Thread 2:R[2]++
*9 Thread 2:将R[2]写回至x(x=2)
*10 Thread 2:unlock()
其实,这里更值得讨论的一个问题是memory visibility(内存可见性)。例如,在Thread 1将R[1]的值写回至x的这一步中,如果Thread 1只是将值放到了这个CPU核的write buffer(write buffer是多核CPU中为于优化写性能的一种硬件)里,而未将最新值直接更新至内存,那么处在另一个CPU核上的Thread 2真的有可能在第7步时读到的是x的旧值0,这下该怎么办?这个问题其实就是共享变量的值何时能被其他线程可见的问题。
好在正是因为内存可见性在共享内存的并行编程中如此的重要,所以以pthread为代表的线程库早就规定好了自己的内存模型,其中就包括了memory visibility的定义:
Memory Visibility
- When will changes of shared data be visible to other threads?
- Pthreads standard guarantees basic memory visibility rules
» thread creation
• memory state before calling pthread_create(…) is visible to created thread
» mutex unlocking (also combined with condition variables)
• memory state before unlocking a mutex is visible to thread which locks same mutex
» thread termination (i.e. entering state “terminated”)
• memory state before termination is visible to thread which joins with terminated thread
» condition variables
• memory state before notifying waiting threads is visible to woke up threads
说简单点,Pthreads线程库帮程序员保证了pthread mutex(spin lock也一样)所保护的临界区内共享变量的可见性:即Thread 1一执行完unlock(),x的最新值1一定能被Thread 2看见。(为了实现这一点,Pthreads线程库在实现的时候都会根据相应的硬件平台调用相应的memory barrier来保证内存可见性,感兴趣的同学可以看看nptl的实现)
所以,只要正确的用锁保护好你的共享变量,你的程序就会是线程安全的。《程》中所给出的上述例子其实是错误的。
PS.《程》确实是本好书,作者作为我的同龄人功力还是令人钦佩的。但是这个例子也反映了一个现实:写书最怕的就是出现重大的原则性错误,而博客作为互联网上的公开资源,能更容易的吸收大家的修改意见,保证文章的正确性。
参考文献:
[1] Programming with POSIX Threads
[2] Mutex and Memory Visibility
相关文章推荐
- 《程序员的自我修养》中关于加锁不能保证线程安全的一个错误
- 《程序员的自我修养》中关于加锁不能保证线程安全的一个错误
- 【编程经验】一个关于常量不能被修改的错误
- 关于virtualbox不能为虚拟电脑启动一个新任务报错 GetLastError=1790(其他错误id也可以一试)的问题
- 关于MMC不能打开文件C:\Program Files\Microsoft SQL Server\80\Tools\Binn\SQL Server Enterprise Manager.MSC可能是由于文件不存在,不是一个MMC控制台,或者用后来的MMC版本创建。也可能你没有访问此文件的足够权限
- 关于更新windows Service Pack 3 更新后系统登录出现“一个问题阻止Windows正确检查机器的许可证。错误代码 0x80070002”问题解决方案
- 关于JSP不能通过浏览器直接访问,要通过servlet跳转,但一个jsp文件里面用<iframe>标签包含了另一个jsp的访问问题
- 现在有一个城市销售经理,需要从公司出发,去拜访市内的商家,已知他的位置以及商家的位置,但是由于城市道路交通的原因,他只能在左右中选择一个方向,在上下中选择一个方向,现在问他有多少种方案到达商家地址。给定一个地图map及它的长宽n和m,其中1代表经理位置,2代表商家位置,-1代表不能经过的地区,0代表可以经过的地区,请返回方案数,保证一定存在合法路径。保证矩阵的长宽都小于等于10。
- 一个关于多线程的面试题,网上大多给了错误的答案
- 关于循环条件判断的一个奇怪错误
- 关于XCode不能安装的错误提示
- 数组不是指针——数组地址不能动态分配空间,一个小例子关于指针移动,以及malloc
- 关于ASP访问ACCESS数据的“不能打开注册表关键字”80004005错误的探讨
- [笔记][Cocos2d-x]关于 “不是一个有效的 Android 目标平台” 的编译错误
- 一个关于“OLE DB 提供程序 'sqloledb' 指出该对象中没有任何列”错误的解决方法
- 关于RDLC子报表添加参数 错误“本地报表处理期间出错 。值不能为空。 参数名:value” 错误解决方法
- virtualbox提示错误 不能为虚拟电脑 centos7 打开一个新任务. Unable to load R3 module C:\Program Files\Oracle\Virtual
- 2015-3-27:关于跑程序出现的AWK错误,转载了一个《AWK 简明教程》
- 关于Rawajai框架读取自定义3D模型(.obj)解析时的一个错误??解决办法!!!
- 谷歌大脑科学家亲解 LSTM:一个关于“遗忘”与“记忆”的故事 本文作者:奕欣 2017-01-14 09:46 导语:AI科技评论保证这是相对通俗易懂的一篇入门介绍了,看不懂的话欢迎关注「AI 科技