Warum verwendet ein std::atomic store mit sequentieller Konsistenz XCHG?

Lesezeit: 1 Minute

Leandros

std::atomic<int> my_atomic;
my_atomic.store(1, std::memory_order_seq_cst);

tun ein xchg wenn ein Speicher mit sequentieller Konsistenz angefordert wird?

Sollte technisch gesehen nicht ein normaler Speicher mit einer Lese-/Schreibspeicherbarriere ausreichen? Gleichwertig:

_ReadWriteBarrier(); // Or `asm volatile("" ::: "memory");` for gcc/clang
my_atomic.store(1, std::memory_order_acquire);

Ich spreche explizit von x86 & x86_64. Wo ein Geschäft einen impliziten Erfassungszaun hat.

@ Daniel Langr Beides _ReadWriteBarrier() und asm volatile("" ::: "memory") sind Compiler-Fences und werden nicht in Fence-Anweisungen übersetzt.

– Leandros

5. März 2018 um 10:05 Uhr
@DanielLangr Es geht nicht um den Zaun, sondern darum, warum die ganze Operation so umgesetzt wird xchg im Gegensatz zu einem einfachen mov (was auch atomar ist, vorausgesetzt, das Ziel ist korrekt ausgerichtet).

– Leandros

5. März 2018 um 10:05 Uhr
“Wo ein Geschäft einen impliziten Erwerbszaun hat.” Aber du brauchst sowohl Release- als auch Acquisition-Fence für sequentielle Konsistenz. Die Compiler-Barriere verhindert die Neuordnung nur auf Compiler-Ebene, nicht auf CPU-Ebene.

– Daniel Langr

5. März 2018 um 10:22 Uhr

Danke für die ausführliche Antwort, das klärt alles auf! Ich las die großartigen Artikel von Jeff Preshing, die mich bei dieser Frage zurückließen. Ich habe die implizite Reihenfolge verwirrt.

– Leandros

5. März 2018 um 10:54 Uhr

8578900cookie-checkWarum verwendet ein std::atomic store mit sequentieller Konsistenz XCHG?