so wie ich das sehe sind ein paar Operatoren atomar auf atomaren Typen. Z.B. "++".
Ist den der "==" Operator ebenfalls atomar? Kann ein Vergleich über atomar passieren?

Code als Beispiel ware z.B. so:

std::atomic<bool> myBool = true;
if(myBool == true) // do something

Hier ist doch das laden von myBool atomar und "true" passiert lokal. Also thread-safe ist die Anweisung aber kann man bei "==" von einer atomaren Operation sprechen?

Danke für die Aufklärung

kannst du dir auf Assemblerebene wie folgt vorstellen:

load mybool
test

Es ist also sehr wohl möglich, dass der Thread nach dem Laden von mybool unterbrochen wird, ein anderer Thread läuft und mybool auf False setzt -> Race Condition.

hmm, dann sind also alle Operatoren wie !=, >= <,>, <= nicht thread-sicher.

Welche Implementierung von atomic hat denn Vergleichsoperatoren?

uiistdasSchoen schrieb:

wie sieht es dann beim "&=" Operator aus der laut C++11 doku atomar ist?

Atomar heißt atomar. Der Operator ist sicher.

Ich kann jetzt zwar spontan keine Stelle aus dem Standard zitieren, aber beim Vergleich zwischen T und atomic<T> sollte "operator T() const;" zum Zuge kommen => der Vergleich ist thread safe.

sicher? das steht nun im gegensatz zu ethon_'s Antwort

mybool == true

kannst du dir auf Assemblerebene wie folgt vorstellen:

load mybool
test

Es ist also sehr wohl möglich, dass der Thread nach dem Laden von mybool unterbrochen wird, ein anderer Thread läuft und mybool auf False setzt -> Race Condition.

Das ist vollkommen wurscht.
Selbst wenn das load + test ein atomarer Block wären könnte die Variable sofort nach diesem Block auf false gesetzt werden.

Fehlen würde nur die "Reaktion" im if bzw. else Zweig mit in den atomaren Block rein zu nehmen. Und das können atomics nicht.

Man kann es aber oft gut mit CAS nachbilden. Und mit transactional memory kann man überhaupt einfach so tun als wäre es so.

Ich kann jetzt zwar spontan keine Stelle aus dem Standard zitieren, aber beim Vergleich zwischen T und atomic<T> sollte "operator T() const;" zum Zuge kommen => der Vergleich ist thread safe.

Oh tatsächlich. Ein impliziter Konvertierungsoperator in einer neuen Komponente der Standardbibliothek. Warum machen die so etwas?

hustbaer schrieb:

Man kann es aber oft gut mit CAS nachbilden. Und mit transactional memory kann man überhaupt einfach so tun als wäre es so.

Was kann man nachbilden? Ein Spinlock?

Sind nun Vergleichsoperatoren (==, !=, <= etc) thread-safe im Sinne des C++-Standards? Wie sieht es mit älteren Standards aus? (Atomar sind sie ja nicht wie ich nun gelernt habe)

std::atomic<int> myInt = 9;

myInt = myInt >> 4;

oder

myInt >>= 4;

?

Wenn du wissen willst, was für Operationen atomar sind, wieso nicht einfach in die Doku schauen?

Hat keine Data Races

Was hat keine Data races und warum nicht?

Hat keine Data Races weil alle nebenläufigen Zugriffe auf geteilte Objekte atomic sind. Es gibt aber keine Garantie darüber, welchen Wert myInt am Ende genau haben wird, wenn dieser Code nebenläufig ausgeführt wird. Das einzige, das gesichert ist, ist, dass es sich um einen der möglichen Werte, die aus einer der möglichen Serialisierungen aller Zugriffe resultieren, handelt...

hustbaer schrieb:

Man kann es aber oft gut mit CAS nachbilden. Und mit transactional memory kann man überhaupt einfach so tun als wäre es so.

Was kann man nachbilden? Ein Spinlock?

Atomare "if (cond) do_stuff();" Blöcke.

Mit CAS geht es natürlich nur sehr begrenzt. Und natürlich muss man Retries machen falls einem wer zwischen dem Test und dem CAS für's "updaten" dazwischengefahren ist.

EDIT: Was ich vielleicht dazuschreiben sollte: D.h. ne klassische Spinlock/Mutex muss es oft nicht sein. So Sachen wie "if (a < 123) a++;" lassen sich mit Load + Test + CAS + Retry ganz ohne Spinlock/Mutex machen.
Quasi

auto expected = a.load(std::memory_order_relaxed);        // Load
while (expected < 123)                                    // Test & Retry
    if (a.compare_exchange_weak(expected, expected + 1))  // CAS
        break;