Warum verwendet „std::atomic' „XCHG' für sequenziell konsistente Geschäfte?

Warum std::atomic XCHG für sequentielle Konsistenzspeicher verwendet

Hintergrund

Im Bereich des Multithreadings bietet die Klasse std::atomic eine Mittel für den gleichzeitigen Zugriff auf gemeinsam genutzte Daten über Threads hinweg bei gleichzeitiger Gewährleistung der Datenintegrität. Seine Store-Member-Funktion ermöglicht das Schreiben von Werten in eine atomare Variable mit spezifizierter Speicherordnungssemantik.

Im Fall der sequentiellen Konsistenz (std::memory_order_seq_cst) verwenden x86-Architekturen eine xchg-Anweisung, um atomare Speicher zu implementieren. Diese Anweisung führt einen gleichzeitigen Werteaustausch statt einer einfachen Speicheroperation durch.

Motivation für XCHG

Während es den Anschein haben könnte, dass eine einfache Speicheranweisung mit einer Speicherbarriere gekoppelt ist (z. B. _ReadWriteBarrier() oder asm volatile("" ::: "memory");) würde für sequentielle Konsistenz ausreichen, die Verwendung von xchg hat mehrere Vorteile:

1. Vollständige Speicherbarriere: xchg fungiert aufgrund seines impliziten Sperrpräfixes als vollständiger Speicherzaun auf x86. Dadurch wird sichergestellt, dass alle Speichervorgänge vor und nach xchg geordnet sind, wodurch eine Neuordnung des Speichers wirksam verhindert wird.

2. Die Release-Semantik ist unzureichend: Ein normaler Speichervorgang auf x86 weist eine Release-Semantik auf, die eine Neuordnung bei nachfolgenden Vorgängen, einschließlich Erwerbsladungen, ermöglicht. Sequenzielle Konsistenz erfordert andererseits, dass eine solche Neuordnung verboten ist.

Leistungsüberlegungen

Die Wahl zwischen xchg und mov mfence für Atomspeicher hat Auswirkungen auf die Leistung:

• Skylake: mfence blockiert die Ausführung von ALU-Anweisungen außerhalb der Reihenfolge, während xchg nicht. Allerdings weist xchg eine falsche Abhängigkeit vom zuvor geladenen Wert auf.
• AMD: Das Hardware-Optimierungshandbuch empfiehlt die Verwendung von xchg für sequentielle Konsistenzspeicher.
• GCC/ Clang-Optimierung: Moderne Compiler bevorzugen normalerweise xchg gegenüber mov mfence.

Alternative für Thread-Zäune

Neben der Verwendung von xchg für atomare Speicher gibt es weitere Optionen für die Implementierung von atomaren Thread-Zäunen (auch mit der Speicherreihenfolge seq_cst):

• Sperre zum Stapel hinzufügen
• Sperre oder Dword [rsp], 0

Unterscheidung von Release und Acquire

Es ist wichtig zu beachten, dass:

• Ein Speicher mit sequentieller Konsistenz bedeutet nicht, Semantik zu erwerben.
• asm volatile("" ::: "memory"); ist nur eine Compiler-Barriere und erzwingt keine sequentielle Konsistenz.
• Das Emulieren sequentieller Konsistenz mit Operationen und Zäunen schwächerer Ordnung stimmt möglicherweise nicht vollständig mit dem abstrakten C-Maschinenmodell überein.

Schlussfolgerung

Zusammenfassend lässt sich sagen, dass std::atomic-Speicher mit sequenzieller Konsistenz auf x86-Architekturen xchg aufgrund seiner vollständigen Speicherbarrierewirkung und Kompatibilität mit den Anforderungen der sequenziellen Konsistenz nutzen. Obwohl es alternative Implementierungen gibt, bleibt xchg aufgrund seiner Effizienz und Einhaltung der Branchenempfehlungen eine weit verbreitete Lösung.

Das obige ist der detaillierte Inhalt vonWarum verwendet „std::atomic' „XCHG' für sequenziell konsistente Geschäfte?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!