以下所描述的volatile关键字仅仅针对C/C++语言中的,并不适用于其他语言.
volitate
一个定义为volatile的变量是说这变量可能会被意想不到地改变，这样，编译器就不会去优化这个变量的值了。精确地说就是，优化器在用到这个变量时必须每次都小心地重新读取这个变量的值，而不是使用保存在寄存器里的备份。下面是volatile变量的几个例子：
- 硬件寄存器（如：状态寄存器）
- 一个中断服务子程序中会访问到的非自动变量(Non-automatic variables)
- 多线程应用中被几个任务共享的变量
在多线程的程序中，共同访问的内存当中，多个程序都可以操纵这个变量,你自己的程序是无法判定何时这个变量会发生变化.例如A线程将变量复制到寄存器中,然后进入循环反复检测寄存器中的值是否满足一定的条件(它期待B线程改变变量的值),此时B改变了变量的值,但是这个改变对于A线程已经复制到寄存器中的值并没有影响,于是A就永远处于死循环状态.
问题
一个参数既可以是const还可以是volatile吗？解释为什么。
答：可以是。一个例子是只读的状态寄存器。它是volatile因为它可能被意想不到地改变。它是const因为程序不应该试图去修改它。一个指针可以是volatile 吗？解释为什么。
答：可以。尽管这并不很常见。一个例子是当一个中断服务子程序修改一个指向一个buffer的指针时。下面的函数有什么错误：
int square(volatile int *ptr)
{
return *ptr * *ptr;
}
这段代码的目的是用来返回指针*ptr指向值的平方，但是，由于*ptr指向一个volatile型的参数，编译器将会产生类似于下面的代码:
int square(volatile int *ptr)
{
int a,b;
a = *ptr;
b = *ptr;
return a * b;
}
由于*ptr的值可能会被意想不到的改变，因此a和b可能不是一样的值。结果，这段代码可能会返回不是你所期望的平方值。正确代码如下：
long square(volatile int *ptr)
{
int a;
a = *ptr;
return a * a;
}
当要求使用volatile声明的变量的值的时候，系统总是重新从它所在的内存读取数据，即使它前面的指令刚刚从该处读取过数据，而且读取的数据立刻被保存.
volatile int i = 10;
int a=i;
...//其他代码,并未明确告诉编译器,对i进行过操作
int b =i;
volatile指出i是随时可能发生变化的，每次使用它的时候必须从i的地址中读取，因而编译器生成的汇编代码会重新从i的地址读取数据放在b中。而优化做法是，由于编译器发现两次从i读数据的代码之间的代码没有对i进行过操作，它会自动把上次读的数据放在b中。而不是重新从i里面读。这样以来，如果i是一个寄存器变量或者表示一个端口数据就容易出错，所以说volatile可以保证对特殊地址的稳定访问。
另外一个例子是:for(int i =0; i<100000;i++)这个语句是用来测试空循环的速度的,但是编译器肯定会把它优化掉,根本就不执行.但是如果你写成for(volatile int i=0;i<100000;i++);他就会执行了.
在多线程数据同步中的作用
无锁的共享数据
如果不用锁，多个线程共享的数据使用需要非常小心，如下面这个例子 :
int gCounter;
void Increment(void) { gCounter++; }
int GetCurrent(void) { return gCounter; }
多个线程同时调用 Increment 并不能保证安全，因为 gCounter++ 会被分成三步原子操作 :
- 将当前值读入寄存器
- 寄存器自增
- 将寄存器的值写回内存
volatile并不能够解决上述这种情况.考虑下面的代码:
struct SharedDataStructure gSharedStructure;
int gFlag;
//线程A
gSharedStructure.foo = ...;
gSharedStructure.bar = ...;
gSharedStructure.baz = ...;
gFlag = 1;
...
//线程B
if(gFlag)
UseSharedStructure(&gSharedStructure;);
...
在上面的这一段代码当中,结构体和flag之间因为不存在依赖关系,执行的顺序可能会被编译器修改(compiler reorder).线程A的代码可能是flag先被置为1,然后处理结构体,这样线程 B 的 if 语句内就是不安全的 。这种情况下，可以将gFlag和gSharedStructure 都加上 volatile 关键字，保证编译器按照代码顺序产生机器码。
CPU Memory Reordering
但是在加了 volatile 关键字之后，上述代码在实际执行时仍不能保证安全，因为 CPU 会激进的 reorder 以加快执行速度， 因此内部执行机器码的顺序仍然是未知的，只保证最终结束时的结果与原顺序一致（as-if） 。在这种情况下，如果线程 A 和 B 被分配到两个 CPU 执行，B 的 CPU 实际并不知道 A 的 CPU 执行情况。 因此仍然存在 gFlag 被先修改而 gSharedStructure 未处理的问题。此时可以用 OSMemoryBarrier (libkern/OSAtomic.h)来解决问题，代码修改如下:
//线程A
gSharedStructure.foo = ...;
gSharedStructure.bar = ...;
gSharedStructure.baz = ...;
OSMemoryBarrier();
gFlag = 1;
...
//线程B
if(gFlag) {
OSMemoryBarrier();
UseSharedStructure(&gSharedStructure;);
}
这是gSharedStructure 已经不需要再加 volatile 了 而 gFlag 还要分具体情况
while(1) {
if(gFlag) {
OSMemoryBarrier();
UseSharedStructure(&gSharedStructure;);
}
}
如果是上面这种情形，仍然需要加 volatile，因为在这个代码段里面没有修改 gFlag，编译器就会只读一次 gFlag 值放在缓存里一直用了。
再看另一种情况 :
- (void)method {
if(gFlag) {
OSMemoryBarrier();
UseSharedStructure(&gSharedStructure;);
}
}
这种情况就不需要再给 gFlag 加 volatile 了，因为代码每次是从外部调进来（foreign code），每次都会重新读取 gFlag 。(仍需注意，有可能因为 inline 或者整体的优化导致不是 foreign code） 。
需要使用 volatile 的另外一个例子:
int gCount;
// Thread A:
while(!done) {
work();
gCount++;
}
// Thread B:
while(gCount < total) ;
但这里仍然有个例外，如果声明的是 volatile int64_t gCount 而实际运行在 32-bit CPU 上，CPU 一次原子操作并不能完成变量的读/写，因而仍然不能保证安全。
最后，即使已经熟知 volatile 种种特性，实际仍不推荐使用，因为各种编译器的优化器也可能存在bug.
结论:不要预期在多线程中使用volatile来解决数据的同步问题,该加锁时就加锁
- volatile 在循环中读写一个共享值时非常有用，如果循环中没有 foreign code
- volatile 并不能有效保证多段代码的执行顺序，应用 OSMemoryBarrier 解决
- volatile 在多线程场景下，对那些不能被 CPU 进行原子读写的变量并没有用（32bit/64bit）
- volatile 对有锁或者有其它原子操作方案的复杂类型共享数据来说没有用
- 即使代码能够完美使用了 volatile，也不能保证编译器不出 bug。。
