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

问题描述

我正在尝试创建自旋锁的傻瓜版本.浏览Web时，我在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指令 所有自旋等待循环.该文档还提到等待(某些 延迟)"是指令的伪实现.

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指令的流水线，其中一些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.

输入PAUSE指令:

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屋！