Linux 内核中的内存屏障

内存屏障(memory-barriers)是一个很神奇的东西，内存屏障主要解决了两个问题：

单处理器下的乱序问题和多处理器下的内存同步问题。

 

为什么会乱序

一方面，CPU由于采用指令流水线和超流水线技术，一个指令的执行被分成：取指、译码、访存、执行、写回、等若干个阶段。然后，多条指令可以同时存在于流水线中，同时被执行。可能导致CPU虽然顺序取指令、但有可能会出现“乱序”执行的情况，当然，对于” a++；b = f(a)；c = f”等存在依赖关系的指令，CPU则会在“b= f(a)”执行阶段之前被阻塞；

另一方面，编译器也有可能导致编译器乱序，作为编译优化的一种手段，则试图通过指令重排将这样的两条指令拉开距离, 以至于后一条指令进入CPU的时候，前一条指令结果已经得到了，那么也就不再需要阻塞等待了。比如将指令重排为：

a++; c--; b=f(a);

 

乱序的后果

乱序执行，有了“保证上下文因果关系”这一前提，一般情况下是不会有问题的。因此，在绝大多数情况下，我们写程序都不会去考虑乱序所带来的影响。但是，有些程序逻辑，单纯从上下文是看不出它们的因果关系的。比如：

*addr=5; val=*data;

从表面上看，addr和data是没有什么联系的，完全可以放心的去乱序执行。但是如果这是在某某设备驱动程序中，这两个变量却可能对应到设备的地址端口和数据端口。并且，这个设备规定了，当你需要读写设备上的某个寄存器时，先将寄存器编号设置到地址端口，然后就可以通过对数据端口的读写而操作到对应的寄存器。那么这么一来，对前面那两条指令的乱序执行就可能造成错误。

对于这样的逻辑，我们姑且将其称作隐式的因果关系；而指令与指令之间直接的输入输出依赖，也姑且称作显式的因果关系。CPU或者编译器的乱序是以保持显式的因果关系不变为前提的，但是它们都无法识别隐式的因果关系。再举个例子：

obj->data = xxx; obj->ready = 1;

当设置了data之后，记下标志，然后在另一个线程中可能执行：

if (obj->ready) do_something(obj->data);

虽然这个代码看上去有些别扭，但是似乎没错。不过，考虑到乱序，如果标志被置位先于data被设置，那么结果很可能就杯具了。因为从字面上看，前面的那两条指令其实并不存在显式的因果关系，乱序是有可能发生的。

总的来说，如果程序具有显式的因果关系的话，乱序一定会尊重这些关系；否则，乱序就可能打破程序原有的逻辑。这时候，就需要使用屏障来抑制乱序，以维持程序所期望的逻辑。

 

一个CPU对指令顺序提供如下保证：

(1) On any given CPU, dependent memory accesses will be issued in order, with respect to itself.

如Q = P; D = *Q;将保证其顺序执行

(2) Overlapping loads and stores within a particular CPU will appear to be ordered within that CPU.

重叠的Load和Store操作将保证顺序执行（目标地址相同的Load、Store），如：a = *X; *X = b;

(3) It _must_not_ be assumed that independent loads and stores will be issued in the order given.

(4) It _must_ be assumed that overlapping memory accesses may be merged or discarded.

如*A = X; Y = *A; => STORE *A = X; Y = LOAD *A; / or STORE *A = Y = X;

由此可见，无关的内存操作会被按随机顺序有效的得到执行,但是在CPU与CPU交互时或CPU与IO设备交互时, 这可能会成为问题. 我们需要一些手段来干预编译器和CPU, 使其限制指令顺序。内存屏障就是这样的干预手段. 他们能保证处于内存屏障两边的内存操作满足部分有序.(译注: 这里"部分有序"的意思是, 内存屏障之前的操作都会先于屏障之后的操作, 但是如果几个操作出现在屏障的同一边, 则不保证它们的顺序.)

 

屏障的作用

内存屏障主要有：读屏障、写屏障、通用屏障、优化屏障、几种。
以读屏障为例，它用于保证读操作有序。屏障之前的读操作一定会先于屏障之后的读操作完成，写操作不受影响，同属于屏障的某一侧的读操作也不受影响。类似的，写屏障用于限制写操作。而通用屏障则对读写操作都有作用。而优化屏障则用于限制编译器的指令重排，不区分读写。前三种屏障都隐含了优化屏障的功能。比如：

tmp = ttt; *addr = 5; mb(); val = *data;

有了内存屏障就了确保先设置地址端口，再读数据端口。而至于设置地址端口与tmp的赋值孰先孰后，屏障则不做干预。
有了内存屏障，就可以在隐式因果关系的场景中，保证因果关系逻辑正确。

 

多处理器情况

前面只是考虑了单处理器指令乱序的问题，而在多处理器下，除了每个处理器要独自面对上面讨论的问题之外，当处理器之间存在交互的时候，同样要面对乱序的问题。
一个处理器（记为a）对内存的写操作并不是直接就在内存上生效的，而是要先经过自身的cache。另一个处理器（记为b）如果要读取相应内存上的新值，先得等a的cache同步到内存，然后b的cache再从内存同步这个新值。而如果需要同步的值不止一个的话，就会存在顺序问题。再举前面的一个例子：
  <CPU-a>              <CPU-b>
  obj->data = xxx;
  wmb();               if (obj->ready)
  obj->ready = 1;          do_something(obj->data);

前面也说过，必须要使用屏障来保证CPU-a不发生乱序，从而使得ready标记置位的时候，data一定是有效的。但是在多处理器情况下，这还不够。data和ready标记的新值可能以相反的顺序更新到CPU-b上！
其实这种情况在大多数体系结构下并不会发生。alpha机器可能使用分列的cache结构，每个cache列可以并行工作，以提升效率。而每个cache列上面缓存的数据是互斥的（如果不互斥就还得解决cache列之间的一致性），于是就可能引发cache更新不同步的问题。
假设cache被分成两列，而CPU-a和CPU-b上的data和ready都分别被缓存在不同的cache列上。
首先是CPU-a更新了cache之后，会发送消息让其他CPU的cache来同步新的值，对于data和ready的更新消息是需要按顺序发出的。如果cache只有一列，那么指令执行的顺序就决定了操作cache的顺序，也就决定了cache更新消息发出的顺序。但是现在假设了有两个cache列，可能由于缓存data的cache列比较繁忙而使得data的更新消息晚于ready发出，那么程序逻辑就没法保证了。不过好在SMP下的内存屏障在解决指令乱序问题之外，也将cache更新消息乱序的问题解决了。只要使用了屏障，就能保证屏障之前的cache更新消息先于屏障之后的消息被发出。
然后就是CPU-b的问题。在使用了屏障之后，CPU-a已经保证data的更新消息先发出了，那么CPU-b也会先收到data的更新消息。不过同样，CPU-b上缓存data的cache列可能比较繁忙，导致对data的更新晚于对ready的更新。这里同样会出问题。
所以，在这种情况下，CPU-b也得使用屏障。CPU-a上要使用写屏障，保证两个写操作不乱序，并且相应的两个cache更新消息不乱序。CPU-b上则需要使用读屏障，保证对两个cache单元的同步不乱序。可见，SMP下的内存屏障一定是需要配对使用的。
所以，上面的例子应该改写成：
  <CPU-a>              <CPU-b>
  obj->data = xxx;     if (obj->ready)
  wmb();                   rmb();
  obj->ready = 1;          do_something(obj->data);

CPU-b上使用的读屏障还有一种弱化版本，它不保证读操作的有序性，叫做数据依赖屏障。顾名思义，它是在具有数据依赖情况下使用的屏障，因为有数据依赖（也就是之前所说的显式的因果关系），所以CPU和编译器已经能够保证指令的顺序。
再举个例子：

  <CPU-a>              <CPU-b>
  init(newval);        p = data;
  <write barrier>      <data dependency barrier>
  data = &newval;      val = *p;

这里的屏障就可以保证：如果data指向了newval，那么newval一定是初始化过的。

 

误区

在SMP环境下，内存屏障保证的是“一个CPU的多个操作的顺序”（被另一个CPU所观察到的顺序），而不保证“两个CPU的操作顺序”。
举例来说，有如下事件序列：
CPU-0：a = 5; CPU-0：wmb(); CPU-1：rmb(); CPU-1: i = a;

假设从时间顺序上看，CPU-0对内存a的写操作“a = 5”发生于CPU-1的读操作“ i = a”之前，并且中间使用了内存屏障，那么在CPU-1上，i一定等于5么？
未必！因为内存屏障并不保证“两个CPU的操作顺序”。为什么会是这样呢？
一方面，这样的保证没有必要。两个CPU上执行的操作本身是没有关联的，程序没有要求应该谁先谁后。有可能“a = 5”先执行，也有可能“i = a”先执行，这都符合程序逻辑。只是现在这个case恰好“a = 5”先执行而已。
另一方面，两个CPU的操作孰先孰后，是无法通过外部时间来度量的。也就是说，“a = 5”先于“i = a”这件事情不能以它们发生的先后顺序来度量。假设，CPU-0执行了“a = 5”，一个CPU主频周期之后，CPU-1要执行“i = a”。这时候CPU-1如何知道“a = 5”这件事情已经发生了呢？它若想知道，唯一的办法只能跟其他CPU同步一下缓存，但是缓存同步的时间显然远远大于一个CPU主频周期。同步完成之后呢？且不说缓存同步导致CPU性能变差。的确，现在CPU-1可以知道现在“a = 5”已经发生了，但是“a = 5”到底是发生在同步发起之前还是同步过程中呢？依然没法知道。除非CPU在修改自己的cache的时候给每个内存单元打一个时间戳，并且时间戳层层传递到内存，并且记录下来。（记录时间戳花费的空间可能比元数据还大！）
更进一步，即便有时间戳，假设CPU-0执行“a = 5”、CPU-1执行“a = 3”，这两个操作发生在同一个主频周期，如何度量谁先谁后呢？从时间顺序上显然是没法度量的，因为两个操作是同时发生的，没有先后顺序。但是又非得度量其先后顺序不可，最后a到底等于几总该有个结论吧。度量的标准只能是谁先抢到总线、把a的新值从cache更新到内存，谁就是先者。
所以度量内存操作的先后顺序看的是谁先同步到内存（这一步是串行的，不可能同时发生），而不是看操作发生的时间顺序。可能会这样，CPU-0后执行操作，但是由于种种原因先抢到了总线而先把a更新到内存，那么它就是先者。
那么，CPU在看到内存屏障指令之后，是不是应该立马flush cache，使得内存同步的顺序跟时间顺序更为趋近呢？CPU也许可以这么做。但是其实意义并不大，无论如何内存同步顺序永远不可能与时间顺序完全一致，毕竟CPU是并行工作的，而内存同步是串行的。并且flush cache的开销是巨大的，因为内存屏障的作用范围不是某次内存操作，而是屏障前的所有内存操作，所以要flush只能flush所有的cache。