¿Cuál es el propósito de la instrucción "PAUSA" en x86?

Como dice @Mackie, la canalización se llenará con cmps. Intel tendrá que vaciar esos cmps cuando otro núcleo escriba, lo cual es una operación costosa. Si la CPU no lo descarga, entonces usted tiene una violación de orden de memoria. Un ejemplo de tal violación sería el siguiente:

(Esto comienza con lock1 = lock2 = lock3 = var = 1)

Hilo 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:

Hilo 2:

mov lock3, 0
mov lock1, 0
mov ebx, var # I should know that var is 1 here.

Primero, considere el Hilo 1:

Si cmp lock1, 0; jne spin la rama predice que lock1 no es cero, añade cmp lock3, 0 a la canalización.

En la canalización, cmp lock3, 0 lee lock3 y descubre que es igual a 1.

Ahora, supongamos que el Hilo 1 está tomando su tiempo dulce, y el Hilo 2 comienza a correr rápidamente:

lock3 = 0
lock1 = 0

Ahora, volvamos al Hilo 1:

Digamos que el cmp lock1, 0 finalmente lee lock1, descubre que lock1 es 0, y está contento con su capacidad de predicción de ramas.

Este comando se confirma, y nada se vacían. Medios de predicción de ramificación correctos nada se descarga, incluso con lecturas fuera de orden, ya que el procesador dedujo que no hay dependencia interna. lock3 no depende de lock1 a los ojos de la CPU, por lo que todo está bien.

Ahora, el cmp lock3, 0, que leyó correctamente que lock3 era igual a 1, se confirma.

je end no se toma, y mov var, 0 ejecuta.

En el Hilo 3, ebx es igual a 0. Esto debería haber sido imposible. Esta es la violación de la orden de memoria que Intel debe compensar para.

Ahora, la solución que Intel toma para evitar ese comportamiento no válido, es vaciar. Cuando lock3 = 0 se ejecuta en el Hilo 2, obliga al Hilo 1 a limpiar las instrucciones que usan lock3. El lavado en este caso significa que el hilo 1 no agregará instrucciones a la canalización hasta que se hayan confirmado todas las instrucciones que usan lock3. Antes de que el Hilo 1's cmp lock3 pueda confirmar, el cmp lock1 debe confirmar. Cuando el cmp lock1 intenta confirmar, lee que lock1 es realmente igual a 1, y que la rama la predicción fue un fracaso. Esto hace que el cmp a echaran. Ahora que el Hilo 1 está vaciado, la ubicación de lock3 en la caché del Hilo 1 se establece en 0, y luego el Hilo 1 continúa la ejecución (Esperando lock1). El hilo 2 ahora recibe una notificación de que todos los demás núcleos han vaciado el uso de lock3 y actualizado sus cachés, por lo que el Hilo 2 luego continúa la ejecución (Habrá ejecutado instrucciones independientes mientras tanto, pero la siguiente instrucción fue otra escritura, por lo que probablemente tenga que colgar, a menos que otros núcleos tienen una cola para mantener la escritura pendiente lock1 = 0).

Todo este proceso es costoso, de ahí la PAUSA. La PAUSA ayuda al Hilo 1, que ahora puede recuperarse de la inminente mala interpretación de la rama al instante, y no tiene que limpiar su canalización antes de ramificar correctamente. La PAUSA ayuda de manera similar al Hilo 2, que no tiene que esperar en el lavado del Hilo 1 (como se dijo antes, no estoy seguro de este detalle de implementación, pero si el Hilo 2 intenta escribir bloqueos utilizados por demasiados otros núcleos, el hilo 2 eventualmente tendrá que esperar en los rubores).

Un entendimiento importante es que mientras en mi ejemplo, el flush es requerido, en el ejemplo de Mackie, no lo es. Sin embargo, la CPU no tiene forma de saberlo (no analiza el código en absoluto, aparte de comprobar dependencias de sentencias consecutivas y una caché de predicción de ramificaciones), por lo que la CPU descargará las instrucciones que acceden a lockvar en el ejemplo de Mackie tal como lo hace en el mío, para garantizar la corrección.