volatile限定符{C}

PS: ...Newbie love coding… 

Linux_c一站式编程(volatile限定符介绍)

linux_c的volatile限定符

现在探讨一下编译器优化会对生成的指令产生什么影响，在此基础上介绍C语言的 volatile 限定符。看下面的例子:

我们用recv和send这两个全局变量来模拟设备寄存器。假设某种平台采用内存映射I/O，串口发送寄存器和串口接收寄存器位于固定的内存地址，而recv和send这两个全局变量也有固定的内存地址，所以在这个例子中把它们假想成串口接收寄存器和串口发送寄存器。在main函数中，首先从串口接收三个字节存到buf中，然后把这三个字节取反，依次从串口发送出去(实际的串口设备通常有一些标志位指示是否有数据到达以及是否可以发送下一个字节的数据，通常要先查询这些标志位再做读写操作，在这个例子中我们抓主要矛盾，忽略这些细节.)。我们查看这段代码的反汇编结果:

movz指令把字长较短的值存到字长较长的存储单元中，存储单元的高位用0填充。该指令可以有b（byte）、w（word）、l（long）三种后缀，分别表示单字节、两字节和四字节。比如movzbl 0x804a019,%eax表示把地址0x804a019处的一个字节存到eax寄存器中，而eax寄存器是四字节的，高三字节用0填充，而下一条指令mov %al,0x804a01a中的al寄存器正是eax寄存器的低字节，把这个字节存到地址0x804a01a处的一个字节中。可以用不同的名字单独访问x86寄存器的低8位、次低8位、低16位或者完整的32位，以eax为例，al表示低8位，ah表示次低8位，ax表示低16位，如下图所示:

但如果指定优化选项-O编译，反汇编的结果就不一样了:

前三条语句从串口接收三个字节，而编译生成的指令显然不符合我们的意图：只有第一条语句从内存地址0x804a019读一个字节到寄存器eax中，然后从寄存器al保存到buf[0]，后两条语句就不再从内存地址0x804a019读取, 而是直接把寄存器al的值保存到buf[1]和buf[2]。后三条语句把buf中的三个字节取反再发送到串口，编译生成的指令也不符合我们的意图: 只有最后一条语句把eax的值取反写到内存地址0x804a018了，前两条语句形同虚设，根本不生成指令!

为什么编译器优化的结果会错呢？因为编译器并不知道0x804a018和0x804a019是设备寄存器的地址，把它们当成普通的内存单元了。如果是普通的内存单元，只要程序不去改写它，它就不会变，可以先把内存单元里的值读到寄存器缓存起来，以后每次用到这个值就直接从寄存器读取，这样效率更高，我们知道读寄存器远比读内存要快。另一方面，如果对一个普通的内存单元连续做三次写操作，只有最后一次的值会保存到内存单元中，所以前两次写操作是多余的，可以优化掉。访问设备寄存器的代码这样优化就错了，因为设备寄存器往往具有以下特性:

1. 设备寄存器中的数据不需要改写就可以自己发生变化，每次读上来的值都可能不一样.

2. 连续多次向设备寄存器中写数据并不是在做无用功，而是有特殊意义的 。

用优化选项编译生成的指令明显效率更高，但使用不当会出错，为了避免编译器自作聪明，把不该优化的也优化了，程序员应该明确告诉编译器哪些内存单元的访问是不能优化的，在C语言中可以用volatile限定符修饰变量，就是告诉编译器:“即使在编译时指定了优化选项，每次读这个变量仍然要老老实实从内存读取，每次写这个变量也仍然要老老实实写回内存，不能省略任何步骤！”我们把代码的开头几行改成:

然后指定优化选项-O编译，查看反汇编的结果:

确实每次读recv都从内存地址0x804a019读取，每次写send也都写到内存地址0x804a018了。值得注意的是，每次写send并不需要取出buf中的值，而是取出先前缓存在寄存器eax、edx、ecx中的值，做取反运算然后写下去，这是因为buf并没有用volatile限定，试着在buf的定义前面也加上volatile，再优化编译，再查看反汇编的结果!

优化编译结果:

gcc的编译优化选项有-O0、-O、-O1、-O2、-O3、-Os几种! -O0表示不优化，这是缺省的选项. -O1、-O2和-O3这几个选项一个比一个优化得更多，编译时间也更长。-O和-O1相同。-Os表示为缩小目标文件的尺寸而优化。具体每种选项做了哪些优化可以参考gcc(1)的Man Page!

从上面的例子还可以看到，如果在编译时指定了优化选项，源代码和生成指令的次序可能无法对应，甚至有些源代码可能不对应任何指令，被彻底优化掉了. 这一点在用gdb做源码级调试时尤其需要注意（做指令级调试没关系），在为调试而编译时不要指定优化选项，否则可能无法一步步跟踪源代码的执行过程。

有了volatile限定符, 是可以防止编译器优化对设备寄存器的访问. 但是对于有Cache的平台, 仅仅这样还不够, 还是无法防止Cache优化对设备寄存器的访问! 在访问普通的内存单元时，Cache对程序员是透明的，比如执行了movzbl 0x804a019,%eax这样一条指令，我们并不知道eax的值是真的从内存地址0x804a019读到的，还是从Cache中读到的，如果Cache已经缓存了这个地址的数据就从Cache读，如果Cache没有缓存就从内存读，这些步骤都是硬件自动做的，而不是用指令控制Cache去做的，程序员写的指令中只有寄存器, 内存地址, 而没有Cache, 程序员甚至不需要知道Cache的存在。同样道理，如果执行了mov %al,0x804a01a这样一条指令，我们并不知道寄存器的值是真的写回内存了，还是只写到了Cache中，以后再由Cache写回内存，即使只写到了Cache中而暂时没有写回内存，下次读0x804a01a这个地址时仍然可以从Cache中读到上次写的数据。然而，在读写设备寄存器时Cache的存在就不容忽视了，如果串口发送和接收寄存器的内存地址被Cache缓存了会有什么问题呢？如下图所示:

如果串口发送寄存器的地址被Cahce缓存，CPU执行单元对串口发送寄存器做写操作都写到Cache中去了，串口发送寄存器并没有及时得到数据，也就不能及时发送，CPU执行单元先后发出的1、2、3三个字节都会写到Cache中的同一个单元，最后Cache中只保存了第3个字节，如果这时Cache把数据写回到串口发送寄存器，只能把第3个字节发送出去，前两个字节就丢失了。与此类似，如果串口接收寄存器的地址被Cache缓存，CPU执行单元在读第1个字节时，Cache会从串口接收寄存器读上来缓存，然而串口接收寄存器后面收到的2、3两个字节Cache并不知道，因为Cache把串口接收寄存器当作普通内存单元，并且相信内存单元中的数据是不会自己变的，以后每次读串口接收寄存器时，Cache都会把缓存的第1个字节提供给CPU执行单元。

通常: 有Cache的平台都有办法对某一段地址范围禁用Cache, 一般是在页表中设置的, 可以设定哪些页面允许Cache缓存, 哪些页面不允许Cache缓存, MMU不仅要做地址转换和访问权限检查, 也要和Cache协同工作!

除了设备寄存器需要用volatile限定之外,当一个全局变量被同一进程中的多个控制流程访问时也要用volatile限定，比如信号处理函数和多线程!

何登成-- C/C++ volatile关键词深度剖析

1. 背景

前几天，发了一条如下的微博 (关于C/C++ Volatile关键词的使用建议):

此微博，引发了朋友们的大量讨论：赞同者有之；批评者有之；当然，更多的朋友，是希望我能更详细的解读C/C++ Volatile关键词，来佐证我的微博观点。而这，正是我写这篇博文的初衷：本文，将详细分析C/C++ Volatile关键词的功能 (有多种功能)、Volatile关键词在多线程编程中存在的问题、Volatile关键词与编译器/CPU的关系、C/C++ Volatile与Java Volatile的区别，以及Volatile关键词的起源，希望对大家更好的理解、使用C/C++ Volatile，有所帮助!

 

Volatile，词典上的解释为：易失的；易变的；易挥发的。那么用这个关键词修饰的C/C++变量，应该也能够体现出”易变”的特征。大部分人认识Volatile，也是从这个特征出发，而这也是本文揭秘的C/C++ Volatile的第一个特征。

1. Volatile：易变的

在介绍C/C++ Volatile关键词的”易变”性前，先让我们看看以下的两个代码片段，以及他们对应的汇编指令 (以下用例的汇编代码，均为VS 2008编译出来的Release版本)：

 

• 测试用例一：非Volatile变量
  
  
  

  
  

  b = a + 1;这条语句，对应的汇编指令是：lea ecx, [eax + 1]。由于变量a, 在前一条语句a = fn(c)执行时, 被缓存在了寄存器eax中，因此b = a + 1；语句，可以直接使用仍旧在寄存器eax中的a，来进行计算，对应的也就是汇编：[eax + 1]。
  

• 测试用例二：Volatile变量
  
  
  

与测试用例一唯一的不同之处，是变量a被设置为volatile属性, 一个小小的变化，带来的是汇编代码上很大的变化。a = fn(c)执行后，寄存器ecx中的a，被写回内存：mov dword ptr [esp+0Ch], ecx。然后，在执行b = a + 1；语句时，变量a有重新被从内存中读取出来：mov eax, dword ptr [esp + 0Ch], 而不再直接使用寄存器ecx中的内容. 这一小段就是我上面的大篇幅内容!

1. 小结

从以上的两个用例，就可以看出C/C++ Volatile关键词的第一个特性：易变性。所谓的易变性，在汇编层面反映出来，就是两条语句，下一条语句不会直接使用上一条语句对应的volatile变量的寄存器内容，而是重新从内存中读取。volatile的这个特性，相信也是大部分朋友所了解的特性。

 

在了解了C/C++ Volatile关键词的”易变”特性之后，再让我们接着继续来剖析Volatile的下一个特性：”不可优化”特性。

 

1. Volatile：不可优化的

与前面介绍的”易变”性类似，关于C/C++ Volatile关键词的第二个特性：”不可优化”性，也通过两个对比的代码片段来说明：

 

• 测试用例三：非Volatile变量
  

  
  

  在这个用例中，非volatile变量a，b，c全部被编译器优化掉了 (optimize out)，因为编译器通过分析，发觉a，b，c三个变量是无用的，可以进行常量替换。最后的汇编代码相当简介，高效率。

• 测试用例四：Volatile变量
  

  
  

  测试用例四，与测试用例三类似，不同之处在于，a，b，c三个变量，都是volatile变量。这个区别，反映到汇编语言中，就是三个变量仍旧存在，需要将三个变量从内存读入到寄存器之中，然后再调用printf()函数。

1. 小结

从测试用例三、四，可以总结出C/C++ Volatile关键词的第二个特性：“不可优化”特性。volatile告诉编译器，不要对我这个变量进行各种激进的优化，甚至将变量直接消除，保证程序员写在代码中的指令，一定会被执行。相对于前面提到的第一个特性：”易变”性，”不可优化”特性可能知晓的人会相对少一些。但是，相对于下面提到的C/C++ Volatile的第三个特性，无论是”易变”性，还是”不可优化”性，都是Volatile关键词非常流行的概念。

 

1. Volatile：顺序性

 

C/C++ Volatile关键词前面提到的两个特性，让Volatile经常被解读为一个为多线程而生的关键词：一个全局变量，会被多线程同时访问/修改，那么线程内部，就不能假设此变量的不变性，并且基于此假设，来做一些程序设计。当然，这样的假设，本身并没有什么问题，多线程编程，并发访问/修改的全局变量，通常都会建议加上Volatile关键词修饰，来防止C/C++编译器进行不必要的优化。但是，很多时候，C/C++ Volatile关键词，在多线程环境下，会被赋予更多的功能，从而导致问题的出现。

 

回到本文背景部分我的那篇微博，我的这位朋友，正好犯了一个这样的问题。其对C/C++ Volatile关键词的使用，可以抽象为下面的伪代码：

这段伪代码，声明另一个Volatile的flag变量。一个线程(Thread1)在完成一些操作后，会修改这个变量。而另外一个线程(Thread2)，则不断读取这个flag变量，由于flag变量被声明了volatile属性，因此编译器在编译时，并不会每次都从寄存器中读取此变量，同时也不会通过各种激进的优化，直接将if (flag == true)改写为if (false == true)。只要flag变量在Thread1中被修改，Thread2中就会读取到这个变化，进入if条件判断，然后进入if内部进行处理。在if条件的内部，由于flag == true，那么假设Thread1中的something操作一定已经完成了，在基于这个假设的基础上，继续进行下面的other things操作。

 

通过将flag变量声明为volatile属性，很好的利用了本文前面提到的C/C++ Volatile的两个特性：”易变”性；”不可优化”性。按理说，这是一个对于volatile关键词的很好应用，而且看到这里的朋友，也可以去检查检查自己的代码，我相信肯定会有这样的使用存在。

 

但是，这个多线程下看似对于C/C++ Volatile关键词完美的应用，实际上却是有大问题的。问题的关键，就在于前面标红的文字：由于flag = true，那么假设Thread1中的something操作一定已经完成了。flag == true，为什么能够推断出Thread1中的something一定完成了？其实既然我把这作为一个错误的用例，答案是一目了然的：这个推断不能成立，你不能假设看到flag == true后，flag = true;这条语句前面的something一定已经执行完成了。这就引出了C/C++ Volatile关键词的第三个特性：顺序性。

 

同样，为了说明C/C++ Volatile关键词的”顺序性”特征，下面给出三个简单的用例 (注：与上面的测试用例不同，下面的三个用例，基于的是Linux系统，使用的是”GCC: (Debian 4.3.2-1.1) 4.3.2″)：

 

• 测试用例五：非Volatile变量
  

  
  

  一个简单的示例，全局变量A，B均为非volatile变量。通过gcc O2优化进行编译，你可以惊奇的发现，A，B两个变量的赋值顺序被调换了！！！在对应的汇编代码中，B = 0语句先被执行，然后才是A = B + 1语句被执行。
  

  在这里，我先简单的介绍一下C/C++编译器最基本优化原理：保证一段程序的输出，在优化前后无变化。将此原理应用到上面，可以发现，虽然gcc优化了A，B变量的赋值顺序，但是foo()函数的执行结果，优化前后没有发生任何变化，仍旧是A = 1；B = 0。因此这么做是可行的。
  

• 测试用例六：一个Volatile变量
  

  
  

  此测试，相对于测试用例五，最大的区别在于，变量B被声明为volatile变量。通过查看对应的汇编代码，B仍旧被提前到A之前赋值，Volatile变量B，并未阻止编译器优化的发生，编译后仍旧发生了乱序现象。
  

  如此看来，C/C++ Volatile变量，与非Volatile变量之间的操作，是可能被编译器交换顺序的。
  

  通过此用例，已经能够很好的说明，本章节前面，通过flag == true，来假设something一定完成是不成立的。在多线程下，如此使用volatile，会产生很严重的问题。但是，这不是终点，请继续看下面的测试用例七。
  

• 测试用例七：两个Volatile变量
  

  
  

  同时将A，B两个变量都声明为volatile变量，再来看看对应的汇编。奇迹发生了，A，B赋值乱序的现象消失。此时的汇编代码，与用户代码顺序高度一直，先赋值变量A，然后赋值变量B。
  

  如此看来，C/C++ Volatile变量间的操作，是不会被编译器交换顺序的。
  

  
  

1. happens-before

 

通过测试用例六，可以总结出：C/C++ Volatile变量与非Volatile变量间的操作顺序，有可能被编译器交换。因此，上面多线程操作的伪代码，在实际运行的过程中，就有可能变成下面的顺序：

由于Thread1中的代码执行顺序发生变化，flag = true被提前到something之前进行，那么整个Thread2的假设全部失效。由于something未执行，但是Thread2进入了if代码段，整个多线程代码逻辑出现问题，导致多线程完全错误。

 

细心的读者看到这里，可能要提问，根据测试用例七，C/C++ Volatile变量间，编译器是能够保证不交换顺序的，那么能不能将something中所有的变量全部设置为volatile呢？这样就阻止了编译器的乱序优化，从而也就保证了这个多线程程序的正确性。

 

针对此问题，很不幸，仍旧不行。将所有的变量都设置为volatile，首先能够阻止编译器的乱序优化，这一点是可以肯定的。但是，别忘了，编译器编译出来的代码，最终是要通过CPU来执行的。目前，市场上有各种不同体系架构的CPU产品，CPU本身为了提高代码运行的效率，也会对代码的执行顺序进行调整，这就是所谓的CPU Memory Model (CPU内存模型)。关于CPU的内存模型，可以参考这些资料：Memory Ordering From Wiki；Memory Barriers Are Like Source Control Operations From Jeff Preshing；CPU Cache and Memory Ordering From 何登成。下面，是截取自Wiki上的一幅图，列举了不同CPU架构，可能存在的指令乱序。

 

 

从图中可以看到，X86体系(X86，AMD64)，也就是我们目前使用最广的CPU，也会存在指令乱序执行的行为：StoreLoad乱序，读操作可以提前到写操作之前进行。

 

因此，回到上面的例子，哪怕将所有的变量全部都声明为volatile，哪怕杜绝了编译器的乱序优化，但是针对生成的汇编代码，CPU有可能仍旧会乱序执行指令，导致程序依赖的逻辑出错，volatile对此无能为力。

 

其实，针对这个多线程的应用，真正正确的做法，是构建一个happens-before语义。关于happens-before语义的定义，可参考文章：The Happens-Before Relation。下面，用图的形式，来展示happens-before语义：

 

 

如图所示，所谓的happens-before语义，就是保证Thread1代码块中的所有代码，一定在Thread2代码块的第一条代码之前完成。当然，构建这样的语义有很多方法，我们常用的Mutex、Spinlock、RWLock，都能保证这个语义 (关于happens-before语义的构建，以及为什么锁能保证happens-before语义，以后专门写一篇文章进行讨论)。但是，C/C++ Volatile关键词不能保证这个语义，也就意味着C/C++ Volatile关键词，在多线程环境下，如果使用的不够细心，就会产生如同我这里提到的错误。

 

1. 小结

 

C/C++ Volatile关键词的第三个特性：”顺序性”，能够保证Volatile变量间的顺序性，编译器不会进行乱序优化。Volatile变量与非Volatile变量的顺序，编译器不保证顺序，可能会进行乱序优化。同时，C/C++ Volatile关键词，并不能用于构建happens-before语义，因此在进行多线程程序设计时，要小心使用volatile，不要掉入volatile变量的使用陷阱之中。

 

1. Volatile：Java增强

 

在介绍了C/C++ Volatile关键词之后，再简单介绍一下Java的Volatile。与C/C++的Volatile关键词类似，Java的Volatile也有这三个特性，但最大的不同在于：第三个特性，”顺序性”，Java的Volatile有很极大的增强，Java Volatile变量的操作，附带了Acquire与Release语义。所谓的Acquire与Release语义，可参考文章：Acquire and Release Semantics。(这一点，后续有必要的话，可以写一篇文章专门讨论)。Java Volatile所支持的Acquire、Release语义，如下：

 

• 对于Java Volatile变量的写操作，带有Release语义，所有Volatile变量写操作之前的针对其他任何变量的读写操作，都不会被编译器、CPU优化后，乱序到Volatile变量的写操作之后执行。
  

• 对于Java Volatile变量的读操作，带有Acquire语义，所有Volatile变量读操作之后的针对其他任何变量的读写操作，都不会被编译器、CPU优化后，乱序到Volatile变量的读操作之前进行。
  

 

通过Java Volatile的Acquire、Release语义，对比C/C++ Volatile，可以看出，Java Volatile对于编译器、CPU的乱序优化，限制的更加严格了。Java Volatile变量与非Volatile变量的一些乱序操作，也同样被禁止。

 

由于Java Volatile支持Acquire、Release语义，因此Java Volatile，能够用来构建happens-before语义。也就是说，前面提到的C/C++ Volatile在多线程下错误的使用场景，在Java语言下，恰好就是正确的。如下图所示：

 

 

1. Volatile的起源

 

C/C++的Volatile关键词，有三个特性：易变性；不可优化性；顺序性。那么，为什么Volatile被设计成这样呢？要回答这个问题，就需要从Volatile关键词的产生说起。(注：这一小节的内容，参考自C++ and the Perils of Double-Checked Locking论文的第10章节：volatile：A Brief History。这是一篇顶顶好的论文，值得多次阅读，强烈推荐！)

 

Volatile关键词，最早出现于19世纪70年代，被用于处理memory-mapeed I/O (MMIO)带来的问题。在引入MMIO之后，一块内存地址，既有可能是真正的内存，也有可能被映射到一个I/O端口。相对的，读写一个内存地址，既有可能操作内存，也有可能读写的是一个I/O设备。MMIO为什么需要引入Volatile关键词？考虑如下的一个代码片段：

在此代码片段中，指针p既有可能指向一个内存地址，也有可能指向一个I/O设备。如果指针p指向的是I/O设备，那么(1)，(2)中的a，b，就会接收到I/O设备的连续两个字节。但是，p也有可能指向内存，此时，编译器的优化策略，就可能会判断出a，b同时从同一内存地址读取数据，在做完(1)之后，直接将a赋值给b。对于I/O设备，需要防止编译器做这个优化，不能假设指针b指向的内容不变——易变性。

 

同样，代码(3)，(4)也有类似的问题，编译器发现将a，b同时赋值给指针p是无意义的，因此可能会优化代码(3)中的赋值操作，仅仅保留代码(4)。对于I/O设备，需要防止编译器将写操作给彻底优化消失了——”不可优化”性。

 

对于I/O设备，编译器不能随意交互指令的顺序，因为顺序一变，写入I/O设备的内容也就发生变化了——”顺序性”。

 

基于MMIO的这三个需求，设计出来的C/C++ Volatile关键词，所含有的特性，也就是本文前面分析的三个特性：易变性；不可优化性；顺序性。

 

1. 参考资料

[1] Wiki. Volatile variable.

[2] Wiki. Memory ordering.

[3] Scott Meyers; Andrei Alexandrescu. C++ and the Perils of Double-Checked Locking.

[4] Jeff Preshing. Memory Barriers Are Like Source Control Operations.

[5] Jeff Preshing. The Happens-Before Relation.

[6] Jeff Preshing. Acquire and Release Semantics.

[7] 何登成. CPU Cache and Memory Ordering——并发程序设计入门.

[8] Bartosz Milewski. Who ordered sequential consistency?

[9] Andrew Haley. What are we going to do about volatile?

[10] Java Glossary. volatile.

[11] stackoverflow. Why is volatile not considered useful in multithreaded C or C++ programming?

[12] msdn. Volatile fields.

[13] msdn. volatile (C++).

[14] 刘未鹏. 《C++0x漫谈》系列之：多线程内存模型.