正如@Mackie所说，管道将填充 cmp . 当另一个核心写入时，英特尔将不得不刷新那些 cmp ，这是一项昂贵的操作 . 如果CPU没有刷新它，那么您的内存订单违规 . 这种违规行为的一个例子如下：
(以lock1 = lock2 = lock3 = var = 1开头)
线程1：
spin:
cmp lock1, 0
jne spin
cmp lock3, 0 # lock3 should be zero, Thread 2 already ran.
je end # Thus I take this path
mov var, 0 # And this is never run
end:线程2：
mov lock3, 0
mov lock1, 0
mov ebx, var # I should know that var is 1 here.
首先，考虑线程1：
如果 cmp lock1, 0; jne spin branch预测lock1不为零，则将 cmp lock3, 0 添加到管道 .
在管道中， cmp lock3, 0 读取lock3并发现它等于1 .
现在，假设线程1正在消耗它的甜蜜时间，线程2开始快速运行：
lock3 = 0
lock1 = 0
现在，让我们回到主题1：
假设 cmp lock1, 0 最终读取lock1，发现lock1为0，并对其分支预测能力感到高兴 .
此命令提交，没有任何内容被刷新 . 正确的分支预测意味着即使没有顺序读取也不会刷新任何内容，因为处理器推断出没有内部依赖性 . lock3并不依赖于CPU眼中的lock1，所以这一切都没问题 .
现在，正确读取lock3的 cmp lock3, 0 等于1，提交 .
je end 未被执行， mov var, 0 执行 .
在线程3中， ebx 等于0.这应该是不可能的 . 这是英特尔必须违反的内存顺序补偿 .
现在，英特尔采取的避免无效行为的解决方案是刷新 . 当 lock3 = 0 在线程2上运行时，它强制线程1刷新使用lock3的指令 . 在这种情况下冲洗意味着直到使用lock3所有指令一直致力于线程1不会增加指令流水线 . 在线程1的 cmp lock3 可以提交之前， cmp lock1 必须提交 . 当 cmp lock1 尝试提交，它读取锁1实际上等于1，并且该分支预测失败了 . 这会导致 cmp 被抛出 . 现在线程1被刷新， lock3 's location in Thread 1'的缓存设置为 0 ，然后线程1继续执行(等待上 lock1 ) . 线程2现在得到通知，所有其他内核都刷新了 lock3 的使用并更新了它们的缓存，因此线程2然后继续执行(在此期间它将执行独立语句，但是下一条指令是另一个写入因此它可能必须挂起，除非其他核心有一个队列来保存挂起的 lock1 = 0 写入 .
整个过程很昂贵，因此PAUSE . 暂停帮助了线程1，可以从现在即将分支错误预测立即恢复，而且它没有正确的分支之前刷新其管道 . PAUSE同样帮助线程2，它不必等待线程1的刷新(如前所述，我不确定这个实现细节，但如果线程2尝试写入太多其他内核使用的锁，则线程2将最终不得不等待冲洗) .
一个重要的理解是，在我的例子中，需要刷新，在Mackie 's example, it is not. However, the CPU has no way to know (It doesn't中分析代码，除了检查连续语句依赖性和分支预测缓存之外)，因此CPU将刷新访问 lockvar 的指令，只是在Mackie的例子中和我一样，为了保证正确性 .
