Memory Barriers: eine Hardware-Ansicht für Software-Hacker Beispiel 3

Question

Ich kopiere den Text für diese Figur aus dem Original-Papier, Memory Barriers: a Hardware View for Software Hackers.

Tabelle 4 zeigt drei Codefragmente, die gleichzeitig von den CPUs 0, 1 und 2 ausgeführt werden. Alle Variablen sind anfänglich Null.

Beachten Sie, dass weder CPU 1 noch CPU 2 zu Zeile 5 weitergehen können, bis CPU 0 in Zeile 3 auf "b" gesetzt ist. Sobald CPU 1 und 2 ihre Speicherbarrieren auf Leitung 4 ausgeführt haben, wird beides garantiert siehe alle Zuordnungen von CPU 0, die seiner Speicherbarriere in Zeile 2 vorangehen. Auf ähnliche Weise verschachtelt die Speicherbarriere von CPU 0 auf Leitung 8 die von CPU 1 und 2 auf Leitung 4, so daß CPU 0 die Zuweisung zu "e" on line nicht ausführt 9 bis nach seiner Zuordnung zu "a" ist für beide anderen CPUs sichtbar. Daher wird die Aktivierung der CPU 2 in Zeile 9 garantiert nicht ausgelöst.

Für mich Linie 6-9 auf CPU0 scheint überhaupt nicht notwendig, da die Speicherbarriere auf der Linie 2 für CPU 0 und Speichersperre auf der Linie 4 für die CPU 1 & 2 gewährleistet, dass die Wirkung von b=1 wird abgeholt, und alle Geschäfte auch vorher, alias a=1. Dann ist die Bestätigung e == 0 || a == 1 immer erfolgreich.

Ich weiß nicht, ob ich etwas übersehen habe. Jede Klärung wird geschätzt.

Answer 1

Wenn man die Zeilen 6-9 von CPU 0 belässt, würde definitiv das assert() daran gehindert werden zu feuern. Andererseits würde auch das Entfernen des gesamten Codes außer der Bestätigung erfolgen, vorausgesetzt, dass e auf Null initialisiert wird. Beide Modifikationen sind jedoch nicht hilfreich. Der Kernpunkt der Behauptung ist stattdessen die Frage "Ist es CPU 2 möglich, den Zustand e==1&&a==0 am Ende ihrer Ausführung zu sehen?" Wenn Sie es so betrachten, sollten Sie sich überlegen, welche Werte sich in welcher Reihenfolge fortpflanzen.

Aber die Hauptsache, die Sie übersehen haben, ist, dass dieses Papier sehr alt ist, und es hat eine riesige Menge an Fortschritt beim Verständnis und der Formalisierung der Speicherordnung seit damals gegeben. Ich bin dabei, ein neues Kapitel zur Speicherordnung in Is Parallel Programming Hard, And, If So, What Can You Do About It? hinzuzufügen. In der Zwischenzeit kann das Paar der LWN-Artikel here und here hilfreich sein.

Oder wenn Sie den aktuellen Stand des Buches sehen möchten, git clone git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/perfbook.git.