我正在尝试创建一个自旋锁的愚蠢版本。浏览网页时，我在 x86 中发现了一条名为“PAUSE”的汇编指令，它用于向处理器提示当前 CPU 上正在运行自旋锁。英特尔手册和其他可用信息指出
处理器在大多数情况下使用此提示来避免内存顺序冲突，从而大大提高处理器性能。因此，建议在所有自旋等待循环中放置一条 PAUSE 指令。该文档还提到“等待（一些延迟）”是指令的伪实现。
上一段的最后一行很直观。如果我没有成功抓住锁，我必须等待一段时间才能再次抓住锁。
但是，在自旋锁的情况下，内存顺序违规是什么意思？“内存顺序违规”是否意味着自旋锁后指令的推测性加载/存储不正确？
自旋锁问题之前在堆栈溢出时被问过，但内存顺序违规问题仍未得到解答（至少在我的理解中）。
想象一下，处理器将如何执行典型的自旋等待循环：
1 Spin_Lock:
2 CMP lockvar, 0 ; Check if lock is free
3 JE Get_Lock
4 JMP Spin_Lock
5 Get_Lock:
在几次迭代之后，分支预测器将预测条件分支 (3) 将永远不会被采用，并且管道将充满 CMP 指令 (2)。这种情况一直持续到最后另一个处理器将零写入 lockvar。在这一点上，我们的管道充满了推测性的（即尚未提交的）CMP 指令，其中一些指令已经读取了 lockvar 并向下面的条件分支 (3) 报告了一个（不正确的）非零结果（也是推测性的）。这是发生内存顺序冲突的时候。每当处理器“看到”外部写入（来自另一个处理器的写入）时，它就会在其管道中搜索推测性地访问相同内存位置但尚未提交的指令。如果发现任何此类指令，则处理器的推测状态无效，并通过流水线刷新擦除。
不幸的是，这种情况（很可能）会在每次处理器等待自旋锁时重复，并使这些锁比它们应有的速度慢得多。
输入暂停指令：
1 Spin_Lock:
2 CMP lockvar, 0 ; Check if lock is free
3 JE Get_Lock
4 PAUSE ; Wait for memory pipeline to become empty
5 JMP Spin_Lock
6 Get_Lock:
PAUSE 指令将对内存读取“取消流水线化”，因此流水线不会像第一个示例中那样充满推测性 CMP (2) 指令。（即它可能会阻塞流水线，直到所有较旧的内存指令都被提交。）因为 CMP 指令 (2) 顺序执行，所以在 CMP 指令 (2) 读取之后发生外部写入不太可能（即时间窗口更短） lockvar 但在 CMP 提交之前。
当然，“去流水线”也会在自旋锁中浪费更少的能量，并且在超线程的情况下，它不会浪费其他线程可以更好地使用的资源。另一方面，在每个循环退出之前，仍然存在等待发生的分支错误预测。英特尔的文档并未建议 PAUSE 消除管道刷新，但谁知道......
正如@Mackie 所说，管道将充满cmps。当另一个内核写入时，英特尔将不得不刷新这些cmps，这是一项昂贵的操作。如果 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分支预测 lock1 不为零，它会添加cmp lock3, 0到管道中。
在管道中，cmp lock3, 0读取 lock3 并发现它等于 1。
现在，假设线程 1 正在度过美好的时光，线程 2 开始快速运行：
lock3 = 0
lock1 = 0
现在，让我们回到线程 1：
假设cmp lock1, 0finally 读取 lock1，发现 lock1 为 0，并且对其分支预测能力感到满意。
该命令提交，并且没有任何内容被刷新。正确的分支预测意味着没有任何内容被刷新，即使是乱序读取，因为处理器推断没有内部依赖关系。在 CPU 的眼中，lock3 不依赖于 lock1，所以这一切都可以。
现在，cmp lock3, 0正确读取 lock3 等于 1 的 提交。
je end不被采取，并mov var, 0执行。
在线程 3 中，ebx等于 0。这应该是不可能的。这是英特尔必须补偿的内存顺序违规。
现在，英特尔为避免这种无效行为而采取的解决方案是刷新。在lock3 = 0线程 2 上运行时，它会强制线程 1 刷新使用 lock3 的指令。在这种情况下，刷新意味着线程 1 不会向管道添加指令，直到所有使用 lock3 的指令都已提交。在线程 1cmp lock3可以提交之前，cmp lock1必须提交。当cmp lock1尝试提交时，它读取到 lock1 实际上等于 1，并且分支预测失败。这会导致cmp被抛出。现在线程 1 已刷新，lock3线程 1 缓存中的位置设置为0，然后线程 1 继续执行（等待上lock1）。线程 2 现在收到通知，所有其他内核已刷新使用lock3并更新了它们的缓存，因此线程 2 继续执行（同时它会执行独立的语句，但下一条指令是另一个写入，因此它可能必须挂起，除非其他内核有一个队列来保存挂起的lock1 = 0写入）。
整个过程很昂贵，因此暂停。PAUSE 有助于线程 1，它现在可以立即从即将发生的分支错误预测中恢复，并且它不必在正确分支之前刷新其管道。PAUSE 同样有助于线程 2，它不必等待线程 1 的刷新（如前所述，我不确定这个实现细节，但如果线程 2 尝试写入太多其他内核使用的锁，线程 2 将最终必须等待冲洗）。
一个重要的理解是，虽然在我的示例中，刷新是必需的，但在 Mackie 的示例中，它不是。但是，CPU 无法知道（它根本不分析代码，除了检查连续语句依赖关系和分支预测缓存），因此 CPU 将刷新lockvar在 Mackie 示例中访问的指令，就像在我的示例中一样，以保证正确性。