Warum sollte man „memory_order_seq_cst“ für die Stopp-Flag-Einstellung verwenden, während die Überprüfung mit „memory_order_relaxed“ erfolgt?
In seiner Diskussion über atomare Operationen stellt Herb Sutter ein Beispiel für die Verwendung vor von Atomen, einschließlich eines Stop-Flag-Mechanismus:
Worker-Threads überprüfen kontinuierlich das Stop-Flag:
while (!stop.load(std::memory_order_relaxed)) { // Do stuff. }
Gründe für die Nichtverwendung im Store Operation gelockert
Obwohl Herb vorschlägt, dass die Verwendung von „memory_order_relaxed“ zur Überprüfung des Flags aufgrund minimaler Latenzbedenken akzeptabel ist, gibt es keinen spürbaren Leistungsvorteil durch die Verwendung strengerer Speicherreihenfolgen, selbst wenn die Latenz Priorität hätte.
Die Begründung dahinter: Nein Die Verwendung von Lockerungen im Geschäftsbetrieb bleibt unklar, möglicherweise aufgrund eines Versehens oder einer persönlichen Präferenz.
Überlegungen zur Latenz
ISO-C-Standards schreiben keine spezifischen Zeitrahmen für die Sichtbarkeit des Geschäfts vor oder geben Sie Hinweise, wie Sie darauf Einfluss nehmen können. Diese Bestimmungen gelten für alle Atomoperationen, auch für entspannte. Es wird jedoch empfohlen, dass Implementierungen Speicherwerte innerhalb eines angemessenen Zeitrahmens für atomare Lasten zugänglich machen.
In der Praxis wird die spezifische Latenz durch die Implementierung bestimmt, wobei Hardware-Cache-Kohärenzmechanismen typischerweise eine Sichtbarkeit innerhalb von zehn Nanosekunden im besten Fall ermöglichen. Fallszenarien und Submikrosekunden-Intervalle in Fast-Worst-Case-Szenarien.
Auswirkungen auf die Speicherreihenfolge
Unterschiedliche Speicherreihenfolgen für Speicher- oder Ladevorgänge beschleunigen Speichervorgänge in Wirklichkeit nicht Zeitlich steuern sie lediglich, ob Folgevorgänge global sichtbar werden können, während der Laden noch aussteht.
Im Wesentlichen beschleunigen strengere Anordnungen und Barrieren Ereignisse nicht unbedingt, sondern verschieben andere eher, bis der Laden oder die Ladung abgeschlossen ist. Dies gilt für alle realen CPUs, die bestrebt sind, Speicher sofort für andere Kerne sichtbar zu machen.
Daher stellt eine Erhöhung der Speicherreihenfolge, wie z. B. die Verwendung von seq_cst, sicher, dass Änderungen am Stopp-Flag für den Worker sofort sichtbar sind Threads, was ein schnelles Herunterfahren garantiert. Dies hat jedoch keinen Einfluss auf die tatsächliche Sichtbarkeitslatenz.
Vorteile von Relaxed Check
Die Verwendung von „memory_order_relaxed“ für den Prüfvorgang hat mehrere Vorteile:
Zusätzliche Überlegungen
Herb erkennt korrekt, dass die Verwendung von „relaxed“ für das Dirty-Flag aufgrund der von thread.join bereitgestellten Synchronisierung auch akzeptabel ist. Es sollte jedoch beachtet werden, dass Dirty Atomizität erfordert, um gleichzeitige Schreibvorgänge desselben Werts zu verhindern, was nach ISO-C-Standards immer noch als Datenwettlauf gilt.
Zusammenfassend lässt sich sagen, dass die Verwendung von „memory_order_seq_cst“ zum Setzen des Stoppflags eine sofortige Sicherstellung gewährleistet Wenn Sie die Sichtbarkeit für Arbeitsthreads verbessern, ergibt sich kein Leistungsvorteil, wenn Sie dies gegenüber dem Ladevorgang lockerer machen. „memory_order_relaxed“ bietet Vorteile hinsichtlich der Parallelität auf Befehlsebene und der Speicherbandbreitennutzung und ist daher in solchen Szenarien die bevorzugte Wahl.
Das obige ist der detaillierte Inhalt vonWarum „memory_order_seq_cst' zum Setzen des Stopp-Flags verwenden, aber „memory_order_relaxed' zum Überprüfen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!