Memory barrier（内存屏障）

理解 Memory barrier（内存屏障）
发布于 2014 年 04 月 21 日2014 年 05 月 15 日 作者 name5566
参考文献列表：
http://en.wikipedia.org/wiki/Memory_barrier
http://en.wikipedia.org/wiki/Out-of-order_execution
https://www.kernel.org/doc/Documentation/memory-barriers.txt

本文例子均在 Linux（g++）下验证通过，CPU 为 X86-64 处理器架构。所有罗列的 linux 内核代码也均在（或只在）X86-64 下有效。

本文首先通过范例（以及内核代码）来解释 Memory barrier，然后介绍一个利用 Memory barrier 实现的无锁环形缓冲区。

Memory barrier 简介
程序在运行时内存实际的访问顺序和程序代码编写的访问顺序不一定一致，这就是内存乱序访问。内存乱序访问行为出现的理由是为了提升程序运行时的性能。内存乱序访问主要发生在两个阶段：

编译时，编译器优化导致内存乱序访问（指令重排）
运行时，多 CPU 间交互引起内存乱序访问
Memory barrier 能够让 CPU 或编译器在内存访问上有序。一个 Memory barrier 之前的内存访问操作必定先于其之后的完成。Memory barrier 包括两类：

编译器 barrier
CPU Memory barrier
很多时候，编译器和 CPU 引起内存乱序访问不会带来什么问题，但一些特殊情况下，程序逻辑的正确性依赖于内存访问顺序，这时候内存乱序访问会带来逻辑上的错误，例如：

// thread 1
while (!ok);
do(x);

// thread 2
x = 42;
ok = 1;
此段代码中，ok 初始化为 0，线程 1 等待 ok 被设置为 1 后执行 do 函数。假如说，线程 2 对内存的写操作乱序执行，也就是 x 赋值后于 ok 赋值完成，那么 do 函数接受的实参就很可能出乎程序员的意料，不为 42。

编译时内存乱序访问
在编译时，编译器对代码做出优化时可能改变实际执行指令的顺序（例如 gcc 下 O2 或 O3 都会改变实际执行指令的顺序）：

// test.cpp
int x, y, r;
void f()
{
x = r;
y = 1;
}
编译器优化的结果可能导致 y = 1 在 x = r 之前执行完成。首先直接编译此源文件：

g++ -S test.cpp
得到相关的汇编代码如下：

movl r(%rip), %eax
movl %eax, x(%rip)
movl $1, y(%rip)
这里我们看到，x = r 和 y = 1 并没有乱序。现使用优化选项 O2（或 O3）编译上面的代码（g++ -O2 -S test.cpp），生成汇编代码如下：

movl r(%rip), %eax
movl $1, y(%rip) movl %eax, x(%rip) 我们可以清楚的看到经过编译器优化之后 movl$1, y(%rip) 先于 movl %eax, x(%rip) 执行。避免编译时内存乱序访问的办法就是使用编译器 barrier（又叫优化 barrier）。Linux 内核提供函数 barrier() 用于让编译器保证其之前的内存访问先于其之后的完成。内核实现 barrier() 如下（X86-64 架构）：

/#define barrier() asm volatile(“” ::: “memory”)
现在把此编译器 barrier 加入代码中：

int x, y, r;
void f()
{
x = r;
asm volatile(“” ::: “memory”);
y = 1;
}
这样就避免了编译器优化带来的内存乱序访问的问题了（如果有兴趣可以再看看编译之后的汇编代码）。本例中，我们还可以使用 volatile 这个关键字来避免编译时内存乱序访问（而无法避免后面要说的运行时内存乱序访问）。volatile 关键字能够让相关的变量之间在内存访问上避免乱序，这里可以修改 x 和 y 的定义来解决问题：

volatile int x, y;
int r;
void f()
{
x = r;
y = 1;
}
现加上了 volatile 关键字，这使得 x 相对于 y、y 相对于 x 在内存访问上有序。在 Linux 内核中，提供了一个宏 ACCESS_ONCE 来避免编译器对于连续的 ACCESS_ONCE 实例进行指令重排。其实 ACCESS_ONCE 实现源码如下：

/#define ACCESS_ONCE(x) ((volatile typeof(x) )&(x))
此代码只是将变量 x 转换为 volatile 的而已。现在我们就有了第三个修改方案：

int x, y, r;
void f()
{
ACCESS_ONCE(x) = r;
ACCESS_ONCE(y) = 1;
}
到此基本上就阐述完了我们的编译时内存乱序访问的问题。下面开始介绍运行时内存乱序访问。

运行时内存乱序访问
在运行时，CPU 虽然会乱序执行指令，但是在单个 CPU 的上，硬件能够保证程序执行时所有的内存访问操作看起来像是按程序代码编写的顺序执行的，这时候 Memory barrier 没有必要使用（不考虑编译器优化的情况下）。这里我们了解一下 CPU 乱序执行的行为。在乱序执行时，一个处理器真正执行指令的顺序由可用的输入数据决定，而非程序员编写的顺序。
早期的处理器为有序处理器（In-order processors），有序处理器处理指令通常有以下几步：

指令获取
如果指令的输入操作对象（input operands）可用（例如已经在寄存器中了），则将此指令分发到适当的功能单元中。如果一个或者多个操作对象不可用（通常是由于需要从内存中获取），则处理器会等待直到它们可用
指令被适当的功能单元执行
功能单元将结果写回寄存器堆（Register file，一个 CPU 中的一组寄存器）
相比之下，乱序处理器（Out-of-order processors）处理指令通常有以下几步：

指令获取
指令被分发到指令队列
指令在指令队列中等待，直到输入操作对象可用（一旦输入操作对象可用，指令就可以离开队列，即便更早的指令未被执行）
指令被分配到适当的功能单元并执行
执行结果被放入队列（而不立即写入寄存器堆）
只有所有更早请求执行的指令的执行结果被写入寄存器堆后，指令执行的结果才被写入寄存器堆（执行结果重排序，让执行看起来是有序的）
从上面的执行过程可以看出，乱序执行相比有序执行能够避免等待不可用的操作对象（有序执行的第二步）从而提高了效率。现代的机器上，处理器运行的速度比内存快很多，有序处理器花在等待可用数据的时间里已经可以处理大量指令了。
现在思考一下乱序处理器处理指令的过程，我们能得到几个结论：

对于单个 CPU 指令获取是有序的（通过队列实现）
对于单个 CPU 指令执行结果也是有序返回寄存器堆的（通过队列实现）
由此可知，在单 CPU 上，不考虑编译器优化导致乱序的前提下，多线程执行不存在内存乱序访问的问题。我们从内核源码也可以得到类似的结论（代码不完全的摘录）：

/#ifdef CONFIG_SMP
/#define smp_mb() mb()
/#else
/#define smp_mb() barrier()
/#endif
这里可以看到，如果是 SMP 则使用 mb，mb 被定义为 CPU Memory barrier（后面会讲到），而非 SMP 时，直接使用编译器 barrier。

在多 CPU 的机器上，问题又不一样了。每个 CPU 都存在 cache（cache 主要是为了弥补 CPU 和内存之间较慢的访问速度），当一个特定数据第一次被特定一个 CPU 获取时，此数据显然不在 CPU 的 cache 中（这就是 cache miss）。此 cache miss 意味着 CPU 需要从内存中获取数据（这个过程需要 CPU 等待数百个周期），此数据将被加载到 CPU 的 cache 中，这样后续就能直接从 cache 上快速访问。当某个 CPU 进行写操作时，它必须确保其他的 CPU 已经将此数据从它们的 cache 中移除（以便保证一致性），只有在移除操作完成后此 CPU 才能安全的修改数据。显然，存在多个 cache 时，我们必须通过一个 cache 一致性协议来避免数据不一致的问题，而这个通讯的过程就可能导致乱序访问的出现，也就是这里说的运行时内存乱序访问。这里不再深入讨论整个细节，这是一个比较复杂的问题，有兴趣可以研究 http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf 一文，其详细的分析了整个过程。

现在通过一个例子来说明多 CPU 下内存乱序访问：

// test2.cpp
/#include