Verwendet „std::atomic' eine versteckte Sperre und wenn ja, wo befindet sie sich?

Wo versteckt std::atomic seine Sperre?

In Datenstrukturen mit mehreren Elementen sind standardmäßige atomare Typen möglicherweise nicht immer gesperrt. frei. Dies wird auf die Unfähigkeit der CPU zurückgeführt, solche Daten ohne die Unterstützung einer Sperre zu verarbeiten. Betrachten Sie zur Veranschaulichung das folgende Beispiel:

#include <iostream>
#include <atomic>

struct foo {
    double a;
    double b;
};

std::atomic<foo> var;

int main()
{
    std::cout << var.is_lock_free() << std::endl;
    std::cout << sizeof(foo) << std::endl;
    std::cout << sizeof(var) << std::endl;
}

Die Ausgabe für Linux/gcc zeigt Folgendes:

0
16
16

Angenommen, der Atomtyp und die Foo-Struktur belegen den gleichen Platz , erscheint es unwahrscheinlich, dass im Atom eine Sperre gespeichert ist. Aber was genau ist die Wahrheit hinter diesem Rätsel?

Sperrposition und Auswirkungen für mehrere Instanzen

Der übliche Ansatz beinhaltet die Verwendung einer Hash-Tabelle mit verschlüsselten Mutexes (oder Spinlocks). an die Adresse des atomaren Objekts. Diese Hash-Funktion bevorzugt die niedrigsten Bits der Adresse als Index in einem Array der Größe 2^n.

Anderenfalls integriert die LLVM std::atomic-Implementierung höhere Adressbits, um automatisches Aliasing zu verhindern. Dadurch wird sichergestellt, dass Objekte, die durch eine signifikante Potenz von 2 getrennt sind, nicht derselben Sperre zugeordnet werden.

Wichtig ist, dass atomare Objekte nur dann sperrenfrei funktionieren, wenn sie im Speicher von verschiedenen Prozessen gemeinsam genutzt werden, wobei jeder Prozess damit ausgestattet ist mit einer eigenen Hash-Tabelle von Sperren.

Kollisionen innerhalb der Hash-Tabelle erfordern möglicherweise Vorsicht. Obwohl dies kein Problem mit der Korrektheit darstellt, könnte es die Leistung beeinträchtigen, indem es Konflikte zwischen mehreren Threads fördert. Dies kommt jedoch relativ selten vor, da sperrenfreie atomare Objekte typischerweise auf bedenklichen Plattformen bevorzugt werden.

Was Deadlocks betrifft, können Sie sicher sein, dass dies kein Problem darstellt, da std::atomic-Funktionen keine Sperren erwerben auf mehreren Objekten gleichzeitig. Folglich versucht der für den Sperrenerwerb verantwortliche Bibliothekscode niemals, eine zusätzliche Sperre zu sichern, während er eine bestehende hält.

Das obige ist der detaillierte Inhalt vonVerwendet „std::atomic' eine versteckte Sperre und wenn ja, wo befindet sie sich?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!