std:: memory_order

std::memory_order gibt an, wie Speicherzugriffe, einschließlich regulärer, nicht-atomarer Speicherzugriffe, um eine atomare Operation herum angeordnet werden sollen. Ohne jegliche Einschränkungen in einem Mehrkernsystem können, wenn mehrere Threads gleichzeitig auf mehrere Variablen lesend und schreibend zugreifen, die Werteänderungen in einer anderen Reihenfolge beobachtet werden, als sie von einem anderen Thread geschrieben wurden. Tatsächlich kann die scheinbare Reihenfolge der Änderungen sogar zwischen mehreren Leser-Threads variieren. Einige ähnliche Effekte können sogar auf Einprozessorsystemen aufgrund von Compiler-Transformationen auftreten, die durch das Speichermodell erlaubt sind.

Das Standardverhalten aller atomaren Operationen in der Bibliothek bietet sequentiell konsistente Reihenfolge (siehe Diskussion unten). Diese Standardeinstellung kann die Leistung beeinträchtigen, aber den atomaren Operationen der Bibliothek kann ein zusätzliches std::memory_order -Argument übergeben werden, um die genauen Einschränkungen anzugeben, die der Compiler und der Prozessor für diese Operation zusätzlich zur Atomarität erzwingen müssen.

Konstanten

Formale Beschreibung

Thread-übergreifende Synchronisation und Speicherreihenfolge bestimmen, wie Auswertungen und Nebeneffekte von Ausdrücken zwischen verschiedenen Ausführungsthreads geordnet werden. Sie werden in folgenden Begriffen definiert:

Sequenced-before

Innerhalb desselben Threads kann Auswertung A sequenced-before Auswertung B sein, wie beschrieben in evaluation order .

Änderungsreihenfolge

Alle Änderungen an einer bestimmten atomaren Variable erfolgen in einer Gesamtordnung, die spezifisch für diese eine atomare Variable ist.

Die folgenden vier Anforderungen sind für alle atomaren Operationen garantiert:

Release-Sequenz

Nach einem release operation A, der auf ein atomares Objekt M angewendet wird, ist die längste zusammenhängende Teilfolge der Modifikationsreihenfolge von M, die besteht aus:

Wird bezeichnet als release sequence headed by A .

Synchronisiert mit

Wenn ein atomarer Speichervorgang in Thread A ein Release-Operation ist, ein atomarer Ladevorgang in Thread B von derselben Variable eine Acquire-Operation ist, und der Ladevorgang in Thread B einen durch den Speichervorgang in Thread A geschriebenen Wert liest, dann synchronisiert der Speichervorgang in Thread A mit dem Ladevorgang in Thread B.

Auch können einige Bibliotheksaufrufe so definiert sein, dass sie synchronize-with anderen Bibliotheksaufrufen in anderen Threads stehen.

Inter-thread Happens-Before

Zwischen Threads, evaluation A inter-thread happens before evaluation B, wenn eines der Folgenden zutrifft:

Strongly happens-before

Unabhängig von Threads, erfolgt Auswertung A strongly happens-before Auswertung B, falls eines der folgenden zutrifft:

Sichtbare Nebeneffekte

Der Nebeneffekt A auf einen Skalar M (ein Schreibvorgang) ist sichtbar in Bezug auf die Wertermittlung B auf M (ein Lesevorgang), wenn beide der folgenden Bedingungen zutreffen:

Wenn Nebeneffekt A in Bezug auf die Wertberechnung B sichtbar ist, dann ist die längste zusammenhängende Teilmenge der Nebeneffekte auf M in modification order , bei der B nicht happen-before dazu steht, bekannt als die visible sequence of side-effects (der Wert von M, bestimmt durch B, wird der durch einen dieser Nebeneffekte gespeicherte Wert sein).

Hinweis: Die Synchronisation zwischen Threads läuft darauf hinaus, Datenrennen zu verhindern (durch das Herstellen von Happens-Before-Beziehungen) und festzulegen, welche Nebeneffekte unter welchen Bedingungen sichtbar werden.

Verbrauchsvorgang

Atomarer Ladevorgang mit memory_order_consume oder stärker ist ein Consume-Operation. Beachten Sie, dass std::atomic_thread_fence stärkere Synchronisierungsanforderungen als eine Consume-Operation stellt.

Acquire-Operation

Atomarer Ladevorgang mit memory_order_acquire oder stärker ist ein Acquire-Operation. Der lock() -Vorgang auf einem Mutex ist ebenfalls eine Acquire-Operation. Beachten Sie, dass std::atomic_thread_fence stärkere Synchronisierungsanforderungen auferlegt als eine Acquire-Operation.

Freigabeoperation

Atomic Store mit memory_order_release oder stärker ist ein Release-Vorgang. Die unlock() -Operation auf einem Mutex ist ebenfalls ein Release-Vorgang. Beachten Sie, dass std::atomic_thread_fence stärkere Synchronisierungsanforderungen als ein Release-Vorgang auferlegt.

Erklärung

Relaxierte Reihenfolge

Atomare Operationen, die mit memory_order_relaxed gekennzeichnet sind, sind keine Synchronisationsoperationen; sie erzwingen keine Reihenfolge zwischen gleichzeitigen Speicherzugriffen. Sie garantieren lediglich Atomarität und Konsistenz der Modifikationsreihenfolge.

Zum Beispiel, mit x und y anfänglich null,

// Thread 1:
r1 = y.load(std::memory_order_relaxed); // A
x.store(r1, std::memory_order_relaxed); // B
// Thread 2:
r2 = x.load(std::memory_order_relaxed); // C 
y.store(42, std::memory_order_relaxed); // D

ist es erlaubt, r1 == r2 == 42 zu produzieren, weil, obwohl A sequenced-before B in Thread 1 ist und C sequenced before D in Thread 2 ist, nichts verhindert, dass D vor A in der Modifikationsreihenfolge von y erscheint und B vor C in der Modifikationsreihenfolge von x erscheint. Der Seiteneffekt von D auf y könnte für den Ladevorgang A in Thread 1 sichtbar sein, während der Seiteneffekt von B auf x für den Ladevorgang C in Thread 2 sichtbar sein könnte. Insbesondere kann dies auftreten, wenn D vor C in Thread 2 abgeschlossen wird, entweder aufgrund von Compiler-Neuanordnungen oder zur Laufzeit.

// Thread 1:
r1 = y.load(std::memory_order_relaxed);
if (r1 == 42)
    x.store(r1, std::memory_order_relaxed);
// Thread 2:
r2 = x.load(std::memory_order_relaxed);
if (r2 == 42)
    y.store(42, std::memory_order_relaxed);

Typische Verwendung für entspannte Speicherordnung ist das Inkrementieren von Zählern, wie etwa die Referenzzähler von std::shared_ptr , da dies lediglich Atomarität erfordert, jedoch keine Reihenfolge oder Synchronisation (beachte, dass das Dekrementieren der std::shared_ptr -Zähler eine Acquire-Release-Synchronisation mit dem Destruktor erfordert).

#include <atomic>
#include <iostream>
#include <thread>
#include <vector>
std::atomic<int> cnt = {0};
void f()
{
    for (int n = 0; n < 1000; ++n)
        cnt.fetch_add(1, std::memory_order_relaxed);
}
int main()
{
    std::vector<std::thread> v;
    for (int n = 0; n < 10; ++n)
        v.emplace_back(f);
    for (auto& t : v)
        t.join();
    std::cout << "Final counter value is " << cnt << '\n';
}

Final counter value is 10000

Release-Acquire-Reihenfolge

Wenn ein atomarer Speichervorgang in Thread A mit memory_order_release gekennzeichnet ist, ein atomarer Ladevorgang in Thread B von derselben Variable mit memory_order_acquire gekennzeichnet ist, und der Ladevorgang in Thread B einen durch den Speichervorgang in Thread A geschriebenen Wert liest, dann synchronisiert der Speichervorgang in Thread A mit dem Ladevorgang in Thread B.

Alle Speicherschreibvorgänge (einschließlich nicht-atomarer und entspannter atomarer), die aus Sicht von Thread A happened-before dem atomaren Speichervorgang liegen, werden in Thread B zu visible side-effects . Das heißt, sobald der atomare Ladevorgang abgeschlossen ist, ist garantiert, dass Thread B alle Speicherschreibvorgänge von Thread A sieht. Diese Zusicherung gilt nur, wenn B tatsächlich den von A gespeicherten Wert oder einen Wert aus später in der Release-Sequenz zurückgibt.

Die Synchronisierung wird nur zwischen den Threads hergestellt, die releasing und acquiring derselben atomaren Variable durchführen. Andere Threads können eine unterschiedliche Reihenfolge von Speicherzugriffen sehen als einer oder beide der synchronisierten Threads.

Auf stark geordneten Systemen — x86, SPARC TSO, IBM Mainframe, etc. — ist Release-Acquire-Reihenfolge für die meisten Operationen automatisch. Für diesen Synchronisationsmodus werden keine zusätzlichen CPU-Befehle ausgegeben; nur bestimmte Compiler-Optimierungen sind betroffen (z.B. ist es dem Compiler untersagt, nicht-atomare Speichervorgänge über den atomaren Store-Release zu verschieben oder nicht-atomare Ladevorgänge früher als den atomaren Load-Acquire durchzuführen). Auf schwach geordneten Systemen (ARM, Itanium, PowerPC) werden spezielle CPU-Lade- oder Memory-Fence-Befehle verwendet.

Gegenseitige Ausschlusssperren, wie std::mutex oder atomare Spinlock , sind ein Beispiel für Release-Acquire-Synchronisation: Wenn die Sperre von Thread A freigegeben und von Thread B erworben wird, muss alles, was im kritischen Abschnitt (vor der Freigabe) im Kontext von Thread A stattgefunden hat, für Thread B (nach dem Erwerb) sichtbar sein, der denselben kritischen Abschnitt ausführt.

#include <atomic>
#include <cassert>
#include <string>
#include <thread>
std::atomic<std::string*> ptr;
int data;
void producer()
{
    std::string* p = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}
void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_acquire)))
        ;
    assert(*p2 == "Hello"); // never fires
    assert(data == 42); // never fires
}
int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}

#include <atomic>
#include <cassert>
#include <thread>
#include <vector>
std::vector<int> data;
std::atomic<int> flag = {0};
void thread_1()
{
    data.push_back(42);
    flag.store(1, std::memory_order_release);
}
void thread_2()
{
    int expected = 1;
    // memory_order_relaxed ist in Ordnung, da dies ein RMW ist,
    // und RMWs (mit beliebiger Ordnung) nach einem Release bilden eine Release-Sequenz
    while (!flag.compare_exchange_strong(expected, 2, std::memory_order_relaxed))
    {
        expected = 1;
    }
}
void thread_3()
{
    while (flag.load(std::memory_order_acquire) < 2)
        ;
    // wenn wir den Wert 2 vom atomaren Flag lesen, sehen wir 42 im Vektor
    assert(data.at(0) == 42); // wird niemals fehlschlagen
}
int main()
{
    std::thread a(thread_1);
    std::thread b(thread_2);
    std::thread c(thread_3);
    a.join(); b.join(); c.join();
}

Release-Consume-Reihenfolge

#include <atomic>
#include <cassert>
#include <string>
#include <thread>
std::atomic<std::string*> ptr;
int data;
void producer()
{
    std::string* p = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}
void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_consume)))
        ;
    assert(*p2 == "Hello"); // never fires: *p2 carries dependency from ptr
    assert(data == 42); // may or may not fire: data does not carry dependency from ptr
}
int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}

Sequenziell konsistente Reihenfolge

Atomare Operationen, die mit memory_order_seq_cst gekennzeichnet sind, ordnen den Speicher nicht nur auf die gleiche Weise wie Release/Acquire-Ordnung (alles, was happened-before eines Speichers in einem Thread war, wird zu einem visible side effect im Thread, der einen Ladevorgang durchführte), sondern stellen auch eine single total modification order aller atomaren Operationen her, die so gekennzeichnet sind.

// Thread 1:
x.store(1, std::memory_order_seq_cst); // A
y.store(1, std::memory_order_release); // B
// Thread 2:
r1 = y.fetch_add(1, std::memory_order_seq_cst); // C
r2 = y.load(std::memory_order_relaxed); // D
// Thread 3:
y.store(3, std::memory_order_seq_cst); // E
r3 = x.load(std::memory_order_seq_cst); // F

Eine sequenzielle Reihenfolge kann in Situationen mit mehreren Produzenten und mehreren Konsumenten erforderlich sein, bei denen alle Konsumenten die Aktionen aller Produzenten in derselben Reihenfolge wahrnehmen müssen.

Totale sequenzielle Ordnung erfordert eine vollständige Memory-Fence-CPU-Anweisung auf allen Multi-Core-Systemen. Dies kann zu einem Performance-Engpass werden, da es die betroffenen Speicherzugriffe zwingt, sich zu jedem Kern zu propagieren.

#include <atomic>
#include <cassert>
#include <thread>
std::atomic<bool> x = {false};
std::atomic<bool> y = {false};
std::atomic<int> z = {0};
void write_x()
{
    x.store(true, std::memory_order_seq_cst);
}
void write_y()
{
    y.store(true, std::memory_order_seq_cst);
}
void read_x_then_y()
{
    while (!x.load(std::memory_order_seq_cst))
        ;
    if (y.load(std::memory_order_seq_cst))
        ++z;
}
void read_y_then_x()
{
    while (!y.load(std::memory_order_seq_cst))
        ;
    if (x.load(std::memory_order_seq_cst))
        ++z;
}
int main()
{
    std::thread a(write_x);
    std::thread b(write_y);
    std::thread c(read_x_then_y);
    std::thread d(read_y_then_x);
    a.join(); b.join(); c.join(); d.join();
    assert(z.load() != 0); // will never happen
}

Beziehung zu volatile

Innerhalb eines Ausführungsstrangs können Zugriffe (Lese- und Schreibvorgänge) über volatile glvalues nicht über beobachtbare Seiteneffekte (einschließlich anderer volatile-Zugriffe) verschoben werden, die sequenced-before oder sequenced-after im selben Thread angeordnet sind. Diese Reihenfolge wird jedoch nicht garantiert von anderen Threads beobachtet, da volatile-Zugriffe keine Thread-übergreifende Synchronisation herstellen.

Zusätzlich sind flüchtige Zugriffe nicht atomar (gleichzeitiges Lesen und Schreiben ist ein Datenwettlauf ) und ordnen den Speicher nicht an (nicht-flüchtige Speicherzugriffe können frei um den flüchtigen Zugriff herum neu geordnet werden).

Eine bemerkenswerte Ausnahme ist Visual Studio, wo mit Standardeinstellungen jeder volatile-Schreibvorgang Release-Semantik und jeder volatile-Lesevorgang Acquire-Semantik hat ( Microsoft Docs ), und somit volatiles für die Synchronisation zwischen Threads verwendet werden kann. Die standardmäßigen volatile -Semantiken sind nicht für die Multithread-Programmierung anwendbar, obwohl sie ausreichend sind für z.B. die Kommunikation mit einem std::signal -Handler, der im selben Thread läuft, wenn auf sig_atomic_t -Variablen angewendet. Die Compiler-Option /volatile:iso kann verwendet werden, um das verhaltenskonforme Verhalten mit dem Standard wiederherzustellen, was die Standardeinstellung ist, wenn die Zielplattform ARM ist.

Siehe auch

Externe Links