上一文最后提到了 Memory Barriers ，即内存屏障。由于对一个 CPU 而言，a = 1; b = 1. 由于在中间加了内存屏障，在 X86 架构下，就是 mfence 指令，此时在上一文中执行时。情况就变成这样了，当 CPU0 发
出 "read invalidate" 消息后，就会開始运行 mfence 指令，该指令把 Store Buffer 中的项都标记一下。然后開始运行 b = 1,此时尽管 cache hint （cache 命中），可是因为 Store Buffer 中存在被标记的项，所以
b 的新值不会直接应用到 cache 中，它也会被记录到 Store Buffer 中，并会等待被 Store Buffer 中被标记的项被应用，CPU0 也会继续运行其他指令。
这样 CPU1 将会看到正确的 a 的值。看似完美的结局。事实上还差那么一点点。
依旧是上一文的小样例。
a 和 b 初始化都为 0。 a 在 CPU1 的 cache 中， b 在 CPU0 的 cache 中。
CPU 0 运行以下的代码：
a = 1;
mfence;
b = 1;
CPU1 运行以下的代码：
while (b != 1);
assert (a == 1);
断言一定能成功吗？ 让我们如果以下的情况发生：
1. CPU0 运行 a = 1, 可是发现 a 不在 cache 中。它就发出 "read invalidate" 消息，而且把 a 的值存在 store buffer 中；
2。
CPU1 运行 b != 1 的比較，读取 b 的值，结果不在 cache 中，由于它不想改写，所以仅仅发一个 "read" 消息出去。
3. CPU0 运行 mfence, 将 Store Buffer 中的项所有标记，然后运行 b = 1, 结果发现 Store Buffer 中有标记的项，所以就把 b 的值也记录在 Store Buffer，这些项是未标记的。
4. CPU1 收到 "read invalidate" 消息，它把这个消息存入 Invalidate Queue 中。并作出回应；
5. CPU0 收到回应，把 a 的值写入 Cache line, 把 b 的值也写入 cache line;
6. CPU0 收到 "read" 消息，并用出回应；
7. CPU1 收到回应，退出循环，此时读取 a 的值，因为 Invalidate 消息还在队列中。此时它会觉得 Cache line 中 a 的值有效，但事实上为旧值，所以断言错误。
非常明显。兵败在了 Invalidate Queue 上。那可不能够向 Store Buffer 一样。弄一个屏障在读取 Cache line 时作一下检查呢？
假设你能想到这里，说明赶上了设计 CPU 的那些家伙。对，这里也能够用一个 mfence.
代码就成了这个样子
while (b != 1);
mfence;
assert(a == 1);
这样当 while (b != 1) 退出循环之后，遇到了 mfence, 它就必须停下来把 Message Queue 中的所以消息应用到 Cache line 中，此时就会发现 a 的 cache line 失效。当再进行读取 a 时，就会发消息给
CPU0 。进而得到正确的结果。
事实上 X86 提供细粒度的指令 lfence (读屏障)， sfence (写屏障)。 mfence(读写屏障)。
lfence: 该指令把当前invalidate queue 里的所有项标记。当 load 动作发生时，假设队列中有标记项。那么 CPU 必须把 Message Queue 中存在的消息所有应用之后，才会运行后面的指令。
这样读取就变得安全；
sfence: 该指令把标记 Store Buffer 中所以已存在的写入记录项。当下次再有写入操作时，即使命中也不会直接应用到 cache 中。而是记录到 Store Buffer 中。
mfence: 兼备以上两条指令的作用。
另一些其他指令具备这种作用，一般如带 lock 前缀的指令等。
所以普通情况下内存屏障须要成对使用。
最终快要完了。
