atomic und test auf wert



  • Hallo,

    ich bin etwas verwirrt: wenn ich eine atomare variable habe, wie teste ich auf z.B. den Wert NULL?

    std::atomic<int> *a;
    // some code
    
    if (a == NULL)
       // do something
    

    Denn der "==" operator ist ja nicht atomar bzw. die if-bedingung im ganzen ist nicht atomar. Muss ich hier einen Mutex verwenden zum locken?

    Danke



  • Du brauchst bei einem Vergleich überhaupt nicht zu locken. Ob ein anderer Thread die Variable währenddessen verändert ist ja schließlich egal.



  • tuxedo schrieb:

    std::atomic<int> *a;
    // some code
    
    if (a == NULL)
       // do something
    

    Denn der "==" operator ist ja nicht atomar bzw. die if-bedingung im ganzen ist nicht atomar. Muss ich hier einen Mutex verwenden zum locken?

    a ist in deinem Beispiel nicht atomar, sondern ein nicht-atomarer pointer auf einen atomaren int . Vergleichen kannst du std::atomic<> -basierte Typen üblicherweise wie
    normale Variablen auch via x == nullptr oder indem du den gekapselten Wert explizit lädst via load()-member-Funktion ( x.load() == nullptr , o.ä.).

    Das macht aber eventuell nicht das was du eigenlich erreichen möchtest. Vielleicht beschreibst du mal konkret, was du vorhast, dann können wir dir eher sagen,
    wie du das mit Atomics erreichen kannst, oder ob Atomics überhaupt die richtige Wahl für das Problem sind.

    Finnegan



  • roflo schrieb:

    Du brauchst bei einem Vergleich überhaupt nicht zu locken. Ob ein anderer Thread die Variable währenddessen verändert ist ja schließlich egal.

    eben nicht. Das hängt davon ab, ob der Compiler den Vergleich in einen einzigen Maschinenbefehl kompeiliert oder eben nicht. Auf einer 32-Bit-CPU ohne (nehmen wir mal an) 64-Bit-Vergleichsbefehl können es zwei Maschinenbefehle sein, und da kann folgendes passieren:

    T1: Test Low == 0 ?
    T2: Set Low != 0
    T2: ...
    T1: Test High == 0 ?

    T1 glaubt nach dem zweiten Test, daß Low == High == 0, obwohl das wegen T2 nicht mehr stimmt.



  • Das hab ich mir auch gedacht. Mir fällt aber kein Fall ein, in welchem soetwas ein Problem darstellt.



  • roflo schrieb:

    Das hab ich mir auch gedacht. Mir fällt aber kein Fall ein, in welchem soetwas ein Problem darstellt.

    Darum geht's nicht.
    Bzw. es ist auch der gänzlich falsche Ansatz wenn man Programme mit Multithreading schreiben will.



  • Ei, was laber ich da, ihr habt recht 😃


Log in to reply