Heim >Backend-Entwicklung >C++ >Warum das Stop-Flag mit „memory_order_seq_cst' setzen, wenn Sie es mit „memory_order_relaxed' überprüfen?

Warum das Stop-Flag mit „memory_order_seq_cst' setzen, wenn Sie es mit „memory_order_relaxed' überprüfen?

DDD
DDDOriginal
2024-11-11 15:22:03599Durchsuche

Why set the stop flag using memory_order_seq_cst, if you check it with memory_order_relaxed?

Warum das Stopp-Flag mit „memory_order_seq_cst“ setzen, wenn Sie es mit „memory_order_relaxed“ überprüfen?

Im Video bespricht Herb Sutter das Verwendung von Atomics, einschließlich eines Beispiels, bei dem ein Hauptthread Arbeitsthreads startet. Die Worker prüfen ein Stoppflag und der Hauptthread setzt das Stoppflag schließlich mithilfe von „memory_order_seq_cst“ auf „true“. Sutter erklärt, dass die Überprüfung des Flags mit „memory_order_relaxed“ akzeptabel ist, da die Verzögerung beim Stoppen eines Threads nicht signifikant ist.

Es stellt sich die Frage, warum das Stop-Flag mit „memory_order_seq_cst“ anstelle von „memory_order_relaxed“ gesetzt wird.

mo_relaxed eignet sich sowohl zum Laden als auch zum Speichern eines Stoppflags

In diesem Szenario gibt es keinen nennenswerten Latenzvorteil durch stärkere Speicherordnungen, selbst wenn die Latenz beim Erkennen einer Änderung an a Stop- oder Keep_running-Flag war wichtig.

Der ISO-C-Standard legt nicht fest, wie schnell Stores sichtbar werden oder was dies beeinflussen könnte. Es ist lediglich erforderlich, dass Implementierungen sicherstellen, dass der letzte durch eine atomare oder Synchronisierungsvorgang zugewiesene Wert innerhalb eines begrenzten Zeitraums für alle anderen Threads sichtbar wird.

Die Latenz zwischen Threads ist in erster Linie ein Problem der Qualität der Implementierung. wobei der Standard die Dinge weit offen lässt. Normale C-Implementierungen kompilieren für einige Architekturen normalerweise nach ASM und legen die Cache-Kohärenzeigenschaften der Hardware offen, was zu einer geringen Latenz zwischen Threads führt.

Auf echter Hardware, die Cache-Kohärenz verwendet, gilt dies nicht für unterschiedliche Speicherreihenfolgen zum Speichern oder Laden Machen Sie Geschäfte schneller und in Echtzeit sichtbar. Sie steuern, ob spätere Vorgänge global sichtbar werden können, während sie darauf warten, dass der Speicher vom Speicherpuffer in den L1d-Cache übertragen wird.

Stärkere Befehle und Barrieren führen im absoluten Sinne nicht dazu, dass die Dinge schneller passieren. Sie verzögern andere Dinge, bis sie relativ zum Speichern oder Laden passieren dürfen.

Leistungsvorteile der Verwendung von „memory_order_relaxed“ für das Laden

Verwenden von „memory_order_relaxed“ für das Laden hat die folgenden Leistungsvorteile:

  • Vermeidet unnötige Wartezeiten bis zum Abschluss der Prüfung und ermöglicht mehr Parallelität auf Befehls- und Speicherebene über Schleifeniterationen hinweg, wenn der Ladevorgang ein „False“ erzeugt.
  • Vermeidet zusätzliche Anweisungen auf ISAs, bei denen ein Acquire- oder SC-Ladevorgang zusätzliche Anweisungen erfordert, wie z. B. 2-Wege-Barriereanweisungen auf einigen Architekturen.

In diesem speziellen Szenario, in dem das Stoppflag selten gesetzt wird, werden die Daten verschwendet Die Arbeit durch Fehlbelastungen ist minimal. Daher überwiegen die Leistungsvorteile der Verwendung von „memory_order_relaxed“ die potenziellen Nachteile.

Das obige ist der detaillierte Inhalt vonWarum das Stop-Flag mit „memory_order_seq_cst' setzen, wenn Sie es mit „memory_order_relaxed' überprüfen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn