“暂停"的目的是什么?x86 中的指令? [英] What is the purpose of the "PAUSE" instruction in x86?

问题描述

我正在尝试创建一个自旋锁的愚蠢版本.在浏览网页时，我在 x86 中遇到了一条名为PAUSE"的汇编指令，该指令用于向处理器提示当前正在此 CPU 上运行自旋锁.英特尔手册和其他可用信息表明

I am trying to create a dumb version of a spin lock. Browsing the web, I came across a assembly instruction called "PAUSE" in x86 which is used to give hint to a processor that a spin-lock is currently running on this CPU. The intel manual and other information available state that

处理器使用这个提示来避免内存顺序违反大多数情况下，这大大提高了处理器性能.为了为此，建议将 PAUSE 指令放置在所有自旋等待循环.该文档还提到等待(一些delay)"是指令的伪实现.

The processor uses this hint to avoid the memory order violation in most situations, which greatly improves processor performance. For this reason, it is recommended that a PAUSE instruction be placed in all spin-wait loops. The documentation also mentions that "wait(some delay)" is the pseudo implementation of the instruction.

上一段的最后一行很直观.如果我抢锁不成功，我必须等待一段时间才能再次抢锁.

The last line of the above paragraph is intuitive. If I am unsuccessful in grabbing the lock, I must wait for some time before grabbing the lock again.

然而，在自旋锁的情况下，内存顺序违反是什么意思?内存顺序违规"是否意味着自旋锁后指令的推测加载/存储不正确?

However, what do we mean by memory order violation in case of a spin lock? Does "memory order violation" mean the incorrect speculative load/store of the instructions after spin-lock?

自旋锁问题之前已经被问到堆栈溢出，但内存顺序违规问题仍未得到解答(至少我的理解是这样).

The spin-lock question has been asked on Stack overflow before but the memory order violation question remains unanswered (at-least for my understanding).

推荐答案

想象一下，处理器将如何执行典型的自旋等待循环:

Just imagine, how the processor would execute a typical spin-wait loop:

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)(也是推测性的)报告了(不正确的)非零结果.这是发生内存顺序冲突的时候.每当处理器看到"外部写入(来自另一个处理器的写入)时，它就会在其管道中搜索推测性访问相同内存位置但尚未提交的指令.如果发现任何此类指令，则处理器的推测状态无效，并通过流水线刷新进行擦除.

After a few iterations the branch predictor will predict that the conditional branch (3) will never be taken and the pipeline will fill with CMP instructions (2). This goes on until finally another processor writes a zero to lockvar. At this point we have the pipeline full of speculative (i.e. not yet committed) CMP instructions some of which already read lockvar and reported an (incorrect) nonzero result to the following conditional branch (3) (also speculative). This is when the memory order violation happens. Whenever the processor "sees" an external write (a write from another processor), it searches in its pipeline for instructions which speculatively accessed the same memory location and did not yet commit. If any such instructions are found then the speculative state of the processor is invalid and is erased with a pipeline flush.

不幸的是，每次处理器等待自旋锁时，这种情况都会(很可能)重复，并使这些锁比它们应有的速度慢得多.

Unfortunately this scenario will (very likely) repeat each time a processor is waiting on a spin-lock and make these locks much slower than they ought to be.

输入暂停指令:

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 之前.

The PAUSE instruction will "de-pipeline" the memory reads, so that the pipeline is not filled with speculative CMP (2) instructions like in the first example. (I.e. it could block the pipeline until all older memory instructions are committed.) Because the CMP instructions (2) execute sequentially it is unlikely (i.e. the time window is much shorter) that an external write occurs after the CMP instruction (2) read lockvar but before the CMP is committed.

当然，去流水线"也会在自旋锁中浪费更少的能量，并且在超线程的情况下，它不会浪费另一个线程可以更好地使用的资源.另一方面，在每次循环退出之前，仍有一个分支错误预测等待发生.英特尔的文档并没有建议 PAUSE 消除管道刷新，但谁知道...

Of course "de-pipelining" will also waste less energy in the spin-lock and in case of hyperthreading it will not waste resources the other thread could use better. On the other hand there is still a branch mis-prediction waiting to occur before each loop exit. Intel's documentation does not suggest that PAUSE eliminates that pipeline flush, but who knows...

这篇关于“暂停"的目的是什么?x86 中的指令?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！