Wie unterscheiden sich memory_order_seq_cst und memory_order_acq_rel?

Stores sind Release-Operationen und Loads sind Acquiring-Operationen für beide. ich weiß das memory_order_seq_cst soll eine zusätzliche Gesamtordnung für alle Operationen auferlegen, aber ich versäume es, ein Beispiel zu erstellen, bei dem dies nicht der Fall ist, wenn alle memory_order_seq_cst werden ersetzt durch memory_order_acq_rel.

Übersehe ich etwas, oder ist der Unterschied nur ein Dokumentationseffekt, dh man sollte es nutzen memory_order_seq_cst wenn man beabsichtigen nicht mit einem entspannteren Modell zu spielen und zu verwenden memory_order_acq_rel beim Einschränken des entspannten Modells?

http://en.cppreference.com/w/cpp/atomic/memory_order hat ein gutes Beispiel ganz unten das geht nur mit memory_order_seq_cst. Im Wesentlichen memory_order_acq_rel stellt Lese- und Schreibreihenfolgen relativ zur atomaren Variable bereit, während memory_order_seq_cst bietet eine globale Lese- und Schreibreihenfolge. Das heißt, die sequentiell konsistenten Operationen sind in allen Threads in derselben Reihenfolge sichtbar.

Das Beispiel läuft darauf hinaus:

bool x= false;
bool y= false;
int z= 0;

a() { x= true; }
b() { y= true; }
c() { while (!x); if (y) z++; }
d() { while (!y); if (x) z++; }

// kick off a, b, c, d, join all threads
assert(z!=0);

Betrieb an z werden von zwei atomaren Variablen geschützt, nicht von einer, daher können Sie die Acquiring-Release-Semantik nicht verwenden, um dies zu erzwingen z wird immer erhöht.

Auf ISAs wie x86, wo Atomic Barriers zugeordnet ist und das eigentliche Maschinenmodell einen Speicherpuffer enthält:

• seq_cst Stores erfordern das Leeren des Store-Puffers, sodass die späteren Lesevorgänge dieses Threads verzögert werden, bis der Store global sichtbar ist.

• acquire oder release tun nicht müssen den Speicherpuffer leeren. Normale x86-Ladevorgänge und -Speicher haben im Wesentlichen acq- und rel-Semantik. (seq_cst plus einen Speicherpuffer mit Speicherweiterleitung.)

  Aber x86 atomare RMW-Operationen werden immer zu befördert seq_cst weil die x86 asm lock Präfix ist eine vollständige Speicherbarriere. Andere ISAs können das locker machen bzw acq_rel RMWs in Asm, wobei die Ladenseite in der Lage ist, begrenzte Nachbestellungen bei späteren Läden vorzunehmen. (Aber nicht auf eine Weise, die den RMW als nicht-atomar erscheinen lassen würde: Ist das atomare Lesen, Ändern und Schreiben für die Zwecke der Bestellung eine oder zwei Operationen?)

https://preshing.com/20120515/memory-reordering-in-the-act erwischt ist ein aufschlussreiches Beispiel für den Unterschied zwischen einem seq_cst-Speicher und einem einfachen Release-Speicher. (Es ist eigentlich mov + mfence vs. einfach mov in x86 asm. In der Praxis xchg ist eine effizientere Möglichkeit, einen seq_cst-Speicher auf den meisten x86-CPUs durchzuführen, aber GCC verwendet mov+mfence)

Fun Fact: Die LDAR-Acquire-Load-Anweisung von AArch64 ist eigentlich eine sequentiell-erwerben, mit einer besonderen Interaktion mit STLR. Erst mit ARMv8.3 LDAPR kann arm64 einfache Akquisitionsoperationen ausführen, die mit früheren Versionen und seq_cst-Speichern (STLR) neu geordnet werden können. (seq_cst Lasten verwenden immer noch LDAR, weil sie diese Interaktion mit STLR benötigen, um die sequentielle Konsistenz wiederherzustellen; seq_cst und release Stores verwenden beide STLR).

Mit STLR / LDAR erhalten Sie sequentielle Konsistenz, müssen aber nur den Speicherpuffer leeren vor dem nächsten LDAR, nicht sofort nach jedem seq_cst-Speicher vor anderen Operationen. Ich denke, echte AArch64-HW implementiert es auf diese Weise, anstatt einfach den Speicherpuffer zu leeren, bevor ein STLR übergeben wird.

Das Verstärken von rel oder acq_rel zu seq_cst durch die Verwendung von LDAR / STLR muss nicht teuer sein, es sei denn, Sie speichern etwas mit seq_cst und laden dann mit seq_cst etwas anderes. Dann ist es genauso schlimm wie x86.

Einige andere ISAs (wie PowerPC) haben eine größere Auswahl an Barrieren und können bis zu verstärken mo_rel oder mo_acq_rel billiger als mo_seq_cst, Aber ihre seq_cst kann nicht so billig sein wie AArch64; seq-cst-Stores benötigen eine vollständige Barriere.

AArch64 ist also eine Ausnahme von der Regel seq_cst Speicher entleeren den Speicherpuffer an Ort und Stelle, entweder mit einem speziellen Befehl oder einem Sperrbefehl danach. Es ist kein Zufall, dass ARMv8 entwickelt wurde nach C++11 / Java / etc. haben sich im Grunde darauf festgelegt, dass seq_cst der Standard für lockless atomare Operationen ist, daher war es wichtig, sie effizient zu gestalten. Und nachdem CPU-Architekten einige Jahre Zeit hatten, über Alternativen zum Bereitstellen von Barriereanweisungen nachzudenken oder einfach nur Anweisungen zum Laden/Speichern zu erhalten/freizugeben oder zu lockern.

Versuchen Sie, einen Dekkers- oder Petersons-Algorithmus nur mit Acquiring/Release-Semantik zu erstellen.

Das wird nicht funktionieren, da die Acquir/Release-Semantik dies nicht bietet [StoreLoad] Zaun.

Im Falle des Dekkers-Algorithmus:

flag[self]=1 <-- STORE
while(true){
    if(flag[other]==0) { <--- LOAD
        break;
    }
    flag[self]=0;
    while(turn==other);
    flag[self]=1        
}

Ohne [StoreLoad] Zaun könnte der Laden vor die Last springen und dann würde der Algorithmus brechen. 2 Threads gleichzeitig würden sehen, dass die andere Sperre frei ist, ihre eigene Sperre setzen und fortfahren. Und jetzt haben Sie 2 Threads im kritischen Abschnitt.

Verwenden Sie weiterhin die Definition und das Beispiel von Speicher_Reihenfolge. Ersetzen Sie jedoch memory_order_seq_cst durch memory_order_release in store und memory_order_acquire in load.

Release-Acquire-Bestellung garantiert alles, was vor a passiert ist Geschäft in einem Thread wird ein sichtbarer Nebeneffekt in dem Thread, der geladen hat. Aber in unserem Beispiel passiert vorher nichts Geschäft sowohl in thread0 als auch in thread1.

x.store(true, std::memory_order_release); // thread0

y.store(true, std::memory_order_release); // thread1

Darüber hinaus ist ohne memory_order_seq_cst die sequentielle Reihenfolge von Thread2 und Thread3 nicht garantiert. Sie können sich vorstellen, dass sie werden:

if (y.load(std::memory_order_acquire)) { ++z; } // thread2, load y first
while (!x.load(std::memory_order_acquire)); // and then, load x

if (x.load(std::memory_order_acquire)) { ++z; } // thread3, load x first
while (!y.load(std::memory_order_acquire)); // and then, load y

Wenn also Thread2 und Thread3 vor Thread0 und Thread1 ausgeführt werden, bedeutet das, dass sowohl x als auch y falsch bleiben, also wird ++z nie berührt, z bleibt 0 und die Bestätigung wird ausgelöst.

Wenn jedoch memory_order_seq_cst ins Spiel kommt, richtet es eine einzige Gesamtmodifikationsreihenfolge aller so gekennzeichneten atomaren Operationen ein. Also in thread2, x.load dann y.load; in Thread3 sind y.load und dann x.load sichere Dinge.