本文详细探讨了C/C++、Java/.NET中的volatile关键字在多线程编程中的应用和限制。指出volatile无法保证原子性和顺序性，可能导致多线程程序出现错误。文章还讨论了Visual Studio对volatile的扩展，但存在潜在问题。同时，对比了volatile与AtomicInteger的区别，并提出了使用volatile的建议，强调在多线程环境下慎用。
这篇文章详细剖析了为什么在多核时代进行多线程编程时需要慎用volatile关键字。
主要内容有：
1. C/C++中的volatile关键字
2. Visual Studio对C/C++中volatile关键字的扩展
3. Java/.NET中的volatile关键字
4. Memory Model（内存模型）
5. Volatile使用建议
1. C/C++中的volatile关键字
1.1 传统用途
C/C++作为系统级语言，它们与硬件的联系是很紧密的。volatile的意思是“易变的”，这个关键字最早就是为了针对那些“异常”的内存操作而准备的。它的效果是让编译器不要对这个变量的读写操作做任何优化，每次读的时候都直接去该变量的内存地址中去读，每次写的时候都直接写到该变量的内存地址中去，即不做任何缓存优化。它经常用在需要处理中断的嵌入式系统中，其典型的应用有下面几种：
a. 避免用通用寄存器对内存读写的优化。编译器常做的一种优化就是：把常用变量的频繁读写弄到通用寄存器中，最后不用的时候再存回内存中。但是如果某个内存地址中的值是由片外决定的（例如另一个线程或是另一个设备可能更改它），那就需要volatile关键字了。（感谢Kenny老师指正）
b. 硬件寄存器可能被其他设备改变的情况。例如一个嵌入式板子上的某个寄存器直接与一个测试仪器连在一起，这样在这个寄存器的值随时可能被那个测试仪器更改。在这种情况下如果把该值设为volatile属性的，那么编译器就会每次都直接从内存中去取这个值的最新值，而不是自作聪明的把这个值保留在缓存中而导致读不到最新的那个被其他设备写入的新值。
c. 同一个物理内存地址M有两个不同的内存地址的情况。例如两个程序同时对同一个物理地址进行读写，那么编译器就不能假设这个地址只会有一个程序访问而做缓存优化，所以程序员在这种情况下也需要把它定义为volatile的。
1.2 多线程程序中的错误用法
看到这里，很多朋友自然会想到：恩，那么如果是两个线程需要同时访问一个共享变量，为了让其中两个线程每次都能读到这个变量的最新值，我们就把它定义为volatile的就好了嘛！我想这个就是多线程程序中volatile之所以引起那么多争议的最大原因。可惜的是，这个想法是错误的。
举例来说，想用volatile变量来做同步（例如一个flag）？错！为什么？很简单，虽然volatile意味着每次读和写都是直接去内存地址中去操作，但是volatile在C/C++现有标准中即不能保证原子性（Atomicity）也不能保证顺序性（Ordering），所以几乎所有试图用volatile来进行多线程同步的方案都是错的。我之前一篇文章介绍了Sequential Consistency模型（后面简称SC），它其实就是我们印象中多线程程序应该有的执行顺序。但是，SC最大的问题是性能太低了，因为CPU/编译器完全没有必要严格按代码规定的顺序（program order）来执行每一条指令。学过体系结构的同学应该知道不管是编译器也好CPU也好，他们最擅长做的事情就是帮你做乱序优化。在串行时代这些乱序优化对程序员来说都是透明的，封装好了的，你不用关心它们到底给你乱序成啥样了，因为它们会保证优化后的程序的运行结果跟你写程序时预期的结果是一模一样的。但是进入多核时代之后，CPU和编译器还会继续做那些串行时代的优化，更重要的是这些优化还会打破你多线程程序的SC模型语义，从而使得多线程程序的实际运行结果与我们所期待的运行结果不一致！
拿X86来说，它的多核内存模型没有严格执行SC，即属于weak ordering（或者叫relax ordering？）。它唯一允许的乱序优化是可以把对不同地址的load操作提到store之前去（即把store x->load y乱序优化成load y -> store x）。而store x -> store y、load x -> load y，以及load y -> store x不允许交换执行顺序。在X86这样的内存模型下，volatile关键字根本就不能保证对不同volatile变量x和y的store x -> load y的操作不会被CPU乱序优化成load y -> store x。
而对多线程读写操作的原子性来说，诸如volatile x=1这样的写操作的原子性其实是由X86硬件保证的，跟volatile没有任何关系。事实上，volatile根本不能保证对没有内存对齐的变量（或者超出机器字长的变量）的读写操作的原子性。
为了有个更直观的理解，我们来看看CPU的乱序优化是如何让volatile在多线程程序中显得如此无力的。下面这个著名的Dekker算法是想用flag1/2和turn来实现两个线程情况下的临界区互斥访问。这个算法关键就在于对flag1/2和turn的读操作（load）是在其写操作（store）之后的，因此这个多线程算法能保证dekker1和dekker2中对gSharedCounter++的操作是互斥的，即等于是把gSharedCounter++放到临界区里去了。但是，多核X86可能会对这个store->load操作做乱序优化，例如dekker1中对flag2的读操作可能会被提到对flag1和turn的写操作之前，这样就会最终导致临界区的互斥访问失效，而gSharedCounter++也会因此产生data race从而出现错误的计算结果。那么为什么多核CPU会对多线程程序做这样的乱序优化呢？因为从单线程的视角来看flag2和flag1、turn是没有依赖关系的，所以CPU当然可以对他们进行乱序优化以便充分利用好CPU里面的流水线（想了解更多细节请参考计算机体系结构相关书籍）。这样的优化虽然从单线程角度来讲没有错，但是它却违反了我们设计这个多线程算法时所期望的那个多线程语义。（想要解决这个bug就需要自己手动添加memory barrier，或者干脆别去实现这样的算法，而是使用类似pthread_mutex_lock这样的库函数，后面我会再讲到这点）
当然，对不同的CPU来说他们的内存模型是不同的。比如说，如果这个程序是在单核上以多线程的方式执行那么它肯定不会出错，因为单核CPU的内存模型是符合SC的。而在例如PowerPC，ARM之类的架构上运行结果到底如何就得去翻它们的硬件手册中内存模型是怎么定义的了。
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
/*
* Dekker's algorithm, implemented on pthreads
*
* To use as a test to see if/when we can make
* memory cons
|
最低0.47元/天 解锁文章
扫一扫
8867
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
