在C/C++嵌入式代码中，你是否经历过以下情况：

• 代码执行正常–直到你打开了编译器优化
• 代码执行正常–直到打开了中断
• 古怪的硬件驱动
• RTOS的任务独立运行正常–直到生成了其他任务

如果你的回答是“yes”，很有可能你没有使用C语言关键字volatile。你并不是唯一的，很多程序员都不能正确使用volatile。不幸的是，大多数c语言书籍对volatile的藐视，只是简单地一带而过。
volatile用于声明变量时的使用的限定符。它告诉编译器该变量值可能随时发生变化，且这种变化并不是代码引起的。给编译器这个暗示是很重要的。在开始前，我们向来看一看volatile的语法。

C语言关键字volatile语法

声明一个变量为volatile，可以在数据类型之前或之后加上关键字volatile。下面的语句，把foo声明一个volatile的整型。

volatile int foo;
int volatile foo;

把指针指向的变量声明为volatile很常见，尤其是I/O寄存器的地址映射。下面的语句，把pReg声明为一个指向8-bit无符号指针，指针指向的内容为volatile。

volatile uint8_t * pReg;
uint8_t volatile * pReg;

volatile的指针指向非volatile的变量很少见（我只使用过一次），但我还是给出相应的语法。

int * volatile p;

如果你在struct或者union前使用volatile关键字，表明struct或者union的所有内容都是volatile。如果这不是你的本意，可以在struct或者union成员上使用volatile关键字。

正确使用C语言关键字volatile

只要变量可能被意外的修改，就需要把该变量声明为volatile。在实际应用中，只有三种类型数据可能被修改：

• 外设寄存器地址映射

• 在中断服务程序中修改全局变量

• 在多线程、多任务应用中，全局变量被多个任务读写

接下来，我们将分别讨论上述三种情况。

外设寄存器

嵌入式系统包含真正的硬件，通常会有复杂的外设。这些外设寄存器的值可能被异步的修改。举个简单的例子，我们要把一个8-bit状态寄存器的地址映射到0x1234。在程序中循环查看该状态寄存器的值是否变为非0。

下面是最容易想到，但错误的实现方法：

当你打开编译器优化时，程序总是执行失败。因为编译器会生成下面的汇编代码：

程序被优化的原因很简单，既然已经把变量的值读入累加器，就没有必要重新一遍，编译器认为值是不会变化的。就这样，在第三行，程序进入了无限死循环。为了告诉编译器我们的真正意图，我们需要修改函数的声明：

编译器生成的汇编代码：

像这样，我们得到了正确的动作。

中断服务程序
**

在中断服务程序中，经常会修改一些全局变量值，来作为主程序中的判断条件。例如，在串口中断服务程序中，可能会检测是否接收到了ETX（假如是消息的结束标识符）字符。如果接收到了ETX，ISR设置一个全局标志位。

错误的做法：

在关闭编译器优化的情况下，程序可能执行正常。然而，任何像样点而优化都会“break”这段程序。问题是编译器并不知道etx_rcvd可能被ISR中被修改。编译器只知道，表达式!ext_rcvd始终为真，你讲用于无法退出循环。结果，循环后面的代码可能被编译器优化掉。

幸运的话，你的编译器可能会发出警告；不幸的话，(或者你不认真的查看编译器警告)，你的程序无法正常执行。当然，你可以责怪编译器执行了“糟糕的优化”。

解决方式是，将变量etx_rcvd声明为volatile，所有问题（当然，也可能是部分问题）就消失了。

多线程应用

在实时系统中，尽管有想queues,pipes等这些同步机制，使用全局变量实现两个任务共享信息的做法依然很常见。即使在你的程序中加入了抢占式调度器，你的编译器依然无法知道什么是上下文切换，或何时发生上下文切换。因此从概念上讲，多任务修改全局变量的的做法与中断服务程序中修改全局变量的做法是相同的。因此，所有这类全局变量都应该声明为volatile。

当打开编译器优化时，这段程序可能执行失败。解决方法是将cntr声明为volatile。

一些编译器允许你把所有的变量隐式的声明为volatile。请抵制这种诱惑，因为它会令你不再思考，当然也会导致生成低效的代码。

另外，也不要责怪优化器或直接把它关掉。现代的优化器已经足够优秀，我已经记不清上次遇到优化bug是什么时候了。相反，我常常看到程序员们错误的使用volatile。

如果你被要求去修改一个很古怪的代码，请在程序中查找一下volatile关键字；如果你什么也没有找到，上面讨论的例子可以向你提供一些解决问题的思路。