例：定义为volatile的结构体成员

考察下面对一个设备硬件寄存器结构类型的定义：

struct devregs{
    unsigned short volatile csr;
    unsigned short const volatile data;
};

我们的原意是希望声明一个设备的硬件寄存器组。其中有一个16bit的CSR控制/状态寄存器，这个寄存器可以由程序向设备写入控制字，也可以由硬件设备设置反映其工作状态。另外还有一个16bit的DATA数据寄存器，这个寄存器只会由硬件来设置，由程序进行读入。

看起来，这个结构的定义没有什么问题，也相当符合实际情况。但是如果执行下面这样的代码时，会发生什么情况呢？

struct devregs * const dvp = DEVADDR;

while ((dvp->csr & (READY | ERROR)) == 0)
    ; /* NULL - wait till done */

通过一个non-volatile的结构体指针，去访问被定义为volatile的结构体成员，编译器将如何处理？答案是：Undefined！C99 标准没有对编译器在这种情况下的行为做规定。所以编译器有可能正确地将dvp->csr作为volatile的变量来处理，使程序运行正常；也有可能就将dvp->csr作为普通的non-volatile变量来处理，在while当中优化为只有开始的时候取值一次，以后每次循环始终使用第一次取来的值而不再从硬件寄存器里读取，这样上面的代码就有可能陷入死循环！！

如果你使用一个volatile的指针来指向一个非volatile的对象。比如将一个non-volatile的结构体地址赋给一个 volatile的指针，这样对volatile指针所指结构体的使用都会被编译器认为是volatile的，即使原本那个对象没有被声明为 volatile。然而反过来，如果将一个volatile对象的地址赋给一个non-volatile的普通指针，通过这个指针访问volatile对象的结果是undefined，是危险的。

所以对于本例中的代码，我们应该修改成这样：

struct devregs{
    unsigned short csr;
    unsigned short data;
};

volatile struct devregs * const dvp = DEVADDR;

这样我们才能保证通过dvp指针去访问结构体成员的时候，都是作为volatile来处理的。

例：定义为volatile的结构体类型

考察如下代码：

volatile struct devregs{
    /* stuff */
} dev1;
......;
struct devregs dev2;

作者的目的也许是希望定义一个volatile的结构体类型，然后顺便定义一个这样的volatile结构体变量dev1。后来又需要一个这种类型的变量，因此又定义了一个dev2。然而，第二次所定义的dev2变量实际上是non-volatile的！！因为实际上在定义结构体类型时的那个 volatile关键字，修饰的是dev1这个变量而不是struct devregs类型的结构体！！

所以这个代码应该改写成这样：

typeof volatile struct devregs{
    /* stuff */
} devregs_t;

devregs_t dev1;
......;
devregs_t dev2;

这样我们才能得到两个volatile的结构体变量。

例：多次的间接指针引用

考察如下代码：

/* DMA buffer descriptor */
struct bd{
    unsigned int state;
    unsigned char *data_buff;
};

struct devregs{
    unsigned int csr;
    struct bd *tx_bd;
    struct bd *rx_bd;
};

volatile struct devregs * const dvp = DEVADDR;

/* send buffer */
dvp->tx_bd->state = READY;

while((dvp->tx_bd->state & (EMPTY | ERROR)) == 0)
    ; /* NULL - wait till done */

这样的代码常用在对一些DMA设备的发送Buffer处理上。通常这些Buffer Descriptor（BD）当中的状态会由硬件进行设置以告诉软件Buffer是否完成发送或接收。但是请注意，上面的代码中对dvp-> tx_bd->state的操作实际上是non-volatile的！这样的操作有可能因为编译器对其读取的优化而导致后面陷入死循环。

因为虽然dvp已经被定义为volatile的指针了，但是也只有其指向的devregs结构才属于volatile object的范围。也就是说，将dvp声明为指向volatile数据的指针可以保障其所指的volatile object之内的tx_bd这个结构体成员自身是volatile变量，但是并不能保障这个指针变量所指的数据也是volatile的（因为这个指针并没有被声明为指向volatile数据的指针）。

要让上面的代码正常工作，可以将数据结构的定义修改成这样：

struct devregs{
    unsigned int csr;
    volatile struct bd *tx_bd;
    volatile struct bd *rx_bd;
};

这样可以保证对state成员的处理也是volatile的。不过最为稳妥和清晰的办法还是这样：

volatile struct devregs * const dvp = DEVADDR;
volatile struct bd *tx_bd = dvp->tx_bd;

tx_bd->state = READY;

while((tx_bd->state & (EMPTY | ERROR)) == 0)
    ; /* NULL - wait till done */

这样在代码里面能绝对保证数据结构的易变性，即使数据结构里面没有定义好也不会有关系。而且对于日后的维护也有好处：因为这样从代码里一眼就能看出哪些数据结构的访问是必须保证volatile的。

例：到底哪个volatile可能无效

struct hw_bd {
    ......;
    volatile unsigned char * volatile buffer;
};

struct hw_bd *bdp;

......;
bdp->buffer = ...; ①
bdp->buffer[i] = ...; ②

        (non-volatile)
bdp -->+-------------+
       |             |
       |   ... ...   |
       |             |
       +-------------+    (volatile)   
       |    buffer   |-->+------------+
       +-------------+   |            |
                         |            |
                         |            |
                         +------------+
                         |  buffer[i] |
                         +------------+
                         |            |
                         |            |
                         +------------+

目前的高级处理器，为了提高内部逻辑元件的利用率以提高运行速度，通常会采用多指令发射、乱序执行等各种措施。现在普遍使用的一些超标量处理器通常能够在一个指令周期内并发执行多条指令。处理器从L1 I-Cache预取了一批指令后，就会分析找出那些互相没有关联可以并发执行的指令，然后送到几个独立的执行单元进行并发执行。比如下面这样的代码（假定编译器不做优化）：

z = x + y;
p = m + n;

CPU就有可能将这两行无关代码分别送到两个算术单元去同时执行。像Freescale的MPC8541这种嵌入式处理器一个指令周期能够加载4条指令、发射2条指令到流水线、用5个独立的执行单元来并发执行。

通常来说访存指令（由LSU单元执行）所需要的指令周期可能很多（可能要几十甚至上百个周期），而一般的算术指令通常在一个指令周期就搞定。所以有 可能代码中的访存指令耗费了多个周期完成执行后，其他几个执行单元可能已经把后面有多条逻辑上无关的算术指令都执行完了，这就产生了乱序。

另外访存指令之间也存在乱序的问题。高级的CPU可以根据自己Cache的组织特性，将访存指令重新排序执行。访问一些连续地址的可能会先执行，因 为这时候Cache命中率高。有的还允许访存的Non-blocking，即如果前面一条访存指令因为Cache不命中，造成长延时的存储访问时，后面的 访存指令可以先执行以便从Cache取数。对写指令的访存乱序有可能造成的错误后果，所以处理器通常有专门的机制（通常是做了个缓冲）保证在出现异常或者 错误的时候，可以丢弃异常点后面的写指令的结果不做写入。

处理器的分支预测功能也能引起并发执行。处理器的分支预测单元有可能直接把两条分支的指令都预取来一块并发执行掉。等到分支判断的结果出来以后，再丢弃错误分支的计算结果。这样在很多情况下可以实现0周期跳转。比如这样的代码（假定编译器不做优化）：

z = x + y; 
if (z > 0) then
    p = m + n;
else
    p = m - n;

看上去如果z不计算出来是无法继续的。但是实际上CPU有可能先把三个加法都同时进行计算，然后根据z=x+y的结果直接挑选正确的p值。

因此，即使是从汇编上看顺序正确的指令，其执行的顺序也是不可预知的。处理器能够保证并发和乱序执行不会得到错误结果，但是如果是对一些硬件寄存器 的操作不能允许乱序的话，程序员就必须把这个情况告诉CPU。告诉的方法就是通过CPU提供的一组同步指令实现，通常在CPU的文档里面有对同步指令的使 用说明。系统函数库里面的内存屏障（rmb/wmb/mb）实际上也是通过这些同步指令实现的。因此在C编码的时候，只要设置好内存屏障，就能告诉CPU 哪些代码是不能乱序的。

受到处理器预取单元的能力限制，处理器每次只能分析一小块指令的并发性，如果指令相隔比较远就无能为力了。但是从编译器的角度来看，编译器能够对很 大一个范围的代码进行分析，能够从更大的范围内分辨出可以并发的指令，并将其尽量靠近排列让处理器更容易预取和并发执行，充分利用处理器的乱序并发功能。 所以现代的高性能编译器在目标码优化上都具备对指令进行乱序优化的能力。并且可以对访存的指令进行进一步的乱序，减少逻辑上不必要的访存，以及尽量提高 Cache命中率和CPU的LSU（load/store unit）的工作效率。所以在打开编译器优化以后，看到生成的汇编码并不严格按照代码的逻辑顺序是正常的。和处理器一样，如果想要告诉编译器不要去对某些 指令乱序优化，也要通过一些方式来告诉编译器。通常可以通过volatile关键字来抑制（注意，不是禁止）编译器对相关变量的访问优化。举个例子：

int *p, *q; 
......; 
*p = 1; 
*p = 2; 
*q = *p;

这样，编译器通常会优化掉前面一个对*p的写入（逻辑上冗余），仅对*p写入2。而对*q赋值的时候，编译器认为此时*q的结果就应该是上次*p的值，会优化掉从*p取数的过程，直接把在寄存器中保存的*p的值给*q（PowrPC汇编）：

（假设r3=p，r4=q） 
li   r5, 2      // r5赋值2 
stw  r5, 0(r3)  // 把r5写到*p 
stw  r5, 0(r4)  // 把r5写到*q

但是如果为p指针加上了volatile关键字，情况就不同了：

volatile int *p; 
int *q; 
......; 
*p = 1; 
*p = 2; 
*q = *p;

在这种情况下，编译器看见*p是volatile的时候，就会：

所以这回的结果如下（PowrPC汇编）：

（假设r3=p，r4=q） 
li   r5, 1      // r5赋值1 
stw  r5, 0(r3)  // 把r5写到*p 
li   r5, 2      // r5赋值2 
stw  r5, 0(r3)  // 把r5写到*p 
lwz  r5, 0(r3)  // 从*p取值到r5 
stw  r5, 0(r4)  // 把r5写到*q

这样编译器会在汇编码级别保证指令有序和不优化掉访存操作。通常简单地使用volatile关键字就可以解决编译器的乱序问题，但是这些指令到了处理器执行的时候，仍然可能被乱序。对于处理器乱序执行的避免就需要用到一组内存屏障函数（barrier）了。

volatile int a;

if (...) { ... }  // sequence point
a = 1;
a = 2;
a = 3;
printk("...");    // sequence point

Barrier函数可以在代码中设置屏障，这个屏障可以阻挡编译器的优化，也可以阻挡处理器的优化。

对于编译器来说，设置任何一个屏障都可以保证：

而对于处理器来说，根据不同的屏障有不同的表现（以下仅仅列举3种最简单的屏障）：

对于驱动开发者来说，一些对设备寄存器的操作，通常是必须保证有序的。在绝大部分情况下，一般都是写操作。对于有序的写操作，必须设置写屏障（wmb）：

/* Mask out everything */ 
im_intctl->ic_simrh = 0x00000000; 
im_intctl->ic_simrl = 0x00000000;

wmb();  

/* Ack everything */ 
im_intctl->ic_sipnrh = 0xffffffff;
im_intctl->ic_sipnrl = 0xffffffff;

同样的，对于一系列的只读操作，也可以简单使用rmb()来保证有序。

如果驱动不仅仅需要在单纯的读指令或者写指令之间有序，还需要保证读写指令之间有序的时候，就需要设置mb()屏障了。下面将演示一个这样的例子：

REG1 = a; 
wmb();  // 保证REG1和REG2的写有序

REG2 = b; 
wmb();  // 保证REG2和REG3的写有序

REG3 = c;

mb();   // 保证在对设备读之前，前面的配置操作都完成（读写之间有序）

*d = REG4; 
rmb();  // 保证REG4和REG5的读有序

*e = REG5;

mb();   // 保证与未来对设备的操作有序 
return;

如果还想进一步了解内存屏障的有关信息，特别是关于多处理器系统中的内存屏障，可以阅读：