C++ / Data Race

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo,

der folgende Code liefert ein Data Race. Das ist kein produktiver Code, 
sondern ein MCE, dass bei mir den Fehler reproduzierbar erzeugt. Die 
Klasse miniClass stellt eine Klasse aus einem Framework nach.

Der Code benutzt die single producer single consumer queue von Cameron 
alias "Moody Camel", https://github.com/cameron314/readerwriterqueue.

Sieht vielleicht jemand, wo das Problem liegt? Ich würde mal vermuten, 
dass das Problem in meinem Code liegt und nicht in Camerons, da seine 
queue doch recht verbreitet ist und so ein einfacher Fall sicher schon 
mal aufgestoßen wäre?

Das Data Race tritt im operator= in der ersten Zeile auf. Wenn man den 
Operator entfernt klappt alles.

Dass das ein Data Race vorliegt, ist eine Meldung von ThreadSanitizer.

Herzlichen Dank für jeden Hinweis

 Timm

#include "atomicops.h"
#include "readerwriterqueue.h"
#include <thread>
#include <chrono>
//==============================================================================

struct miniClass {
    miniClass () {}
    
    miniClass (const miniClass& other) {
        packedData.allocatedData = other.packedData.allocatedData;
    }
    
    miniClass& operator= (miniClass&& other) noexcept {
        packedData.allocatedData = other.packedData.allocatedData;
        return *this;
    }
    
    union PackedData {
        uint8_t* allocatedData;
        uint8_t asBytes[sizeof (uint8_t*)];
    };
    PackedData packedData;
};

moodycamel::ReaderWriterQueue<miniClass> q;

miniClass dequeue() {
    miniClass c;
    q.try_dequeue(c);
    return c;
}

int main (int argc, char* argv[])
{
    std::thread t1([] {
        miniClass c1,c2;
        q.enqueue(c1);
        q.enqueue(c2);
    });
    
    std::thread t2([] {
        miniClass c3,c4;
        c3 = dequeue();
        c4 = dequeue();
    });
    
    t1.join();
    std::this_thread::sleep_for (std::chrono::seconds(1));
    t2.join();
    
    return 0;
}

[Jemand (Gast)]

t2 sieht die Queue entweder als
a) mindestens teilweise gefüllt
oder
b) leer.

Was soll überhaupt

std::this_thread::sleep_for (std::chrono::seconds(1));

bezwecken?

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo,

Jemand schrieb:
> Was soll überhaupt
>

std::this_thread::sleep_for (std::chrono::seconds(1));

> bezwecken?

äh, ja, sorry. Die main muss so aussehen, Fehler bleibt der selbe.

danke

 Timm

int main (int argc, char* argv[])
{
    std::thread t1([] {
        miniClass c1,c2;
        q.enqueue(c1);
        q.enqueue(c2);
    });
    
    std::this_thread::sleep_for (std::chrono::seconds(1));
    
    std::thread t2([] {
        miniClass c3,c4;
        //c3 = dequeue();
        //c4 = dequeue();
        dequeue2(c3);
        dequeue2(c4);
    });
    
    t1.join();
    t2.join();
    
    return 0;
}

[Jemand (Gast)]

Sleep ist kein adäquates Mittel um Threads zu synchronisieren! Wenn du 
statt try_dequeue wait_dequeue verwenden würdest, würde die Queue auf 
ihrere interne Semaphore warten und nicht sofort aufgeben, wenn die 
Queue noch leer ist.

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo jemand,

vielen Dank! Deine Diagnose erscheint zutreffend. Sehr spannende (für 
mich) Lektion.

Könntest Du (oder jemand anderes, der es weiß) mir vielleicht etwas im 
Detail erklären, was da vor sich geht? Fürs Verständnis?

1. Warum reicht 1s nicht aus, dass die queue mit schreiben fertig wird? 
Du hast ja offensichtlich recht, aber warum ist das so?

2. Das Data Race tritt auf, weil die Queue genau in dem Moment mit 
schreiben fertig wird, wie mit lesen? Die Queue ist zwar entsprechend 
abgeschirmt, aber mein Klassenobjekt nicht, weswegen ich dann ein Data 
Race im operator= habe, korrekt?

3. wieso tritt mit default operator= der Effekt nicht auf?

Vielen Dank

 Timm

[Jemand (Gast)]

Ganz konkret ist das Problem, dass man bei Threads grundsätzlich 
annehmen muss, dass diese an einer beliebigen Stelle für unbestimmte 
Zeit blockiert sein können, z. B.

    std::thread t1([] {
// Thread darf genau hier für unbestimmte Zeit stecken bleiben!
        miniClass c1,c2;
        q.enqueue(c1);
        q.enqueue(c2);
    });
    
    std::thread t2([] { // währenddessen kann dieser Thread komplett ausgeführt werden
        miniClass c3,c4;
        c3 = dequeue(); // diese Funktion würde dann kein Ergebnis bringen
        c4 = dequeue();
    });

Die Ergebnisse in t2 hängen also davon ab, ob die Funktionen in t1 vor, 
danach oder gar gleichzeitig ausgeführt werden. Die Function 
wait_dequeue synchronisiert diesen Ablauf, es wird erst weitergemacht, 
wenn die Queue tatsächlich aufgefüllt wurde. t2 kann dann also gar 
nicht vor t1 fertig werden.

Sleep reicht eben nicht aus, weil t1 durchaus länger brauchen darf, als 
die Sleep-Dauer. Mit Semaphore, Mutex und co., wie es die Bibliothek 
intern verwendet, wird das Problem deterministisch gelöst.

[Jemand (Gast)]

Die Warnung vom ThreadSanitizer bekomme ich übrigens auch, wenn ich den 
operator= auskommentiere, aber nur bei g++ mit -O0 oder -O1, mit clang++ 
gar nicht. Das Ding ist also keine Wunderwaffe.

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo,

@jemand
wie gesagt, vielen Dank für Deine Mühe! Sehr hilfreich!

Ich hätte da noch eine Nachfrage:

Das Problem ist ja nicht, dass das try_decueue ein leeres miniClass 
zurückliefert, sondern, dass das Schicksal beschließt unabhängig von 
verstrichener Zeit, das miniClass Objekt erst in dem Moment fertig zu 
stellen, in dem ich es auch auslesen will.

Was dann zum DataRace im operator= führt.

Man könnte also doch sagen, dass mit miniClass Objekten ein korrekter 
Betrieb dieser lockfreien queue nicht möglich ist. Was irgendwo auch gar 
nicht so unlogisch ist, denn wenn die queue warten müsste, bis der 
Konstruktor fertig ist, wäre sie ja eben nicht mehr lock-free.

Kann man also sagen, dass eine lock-free queue nur mit pod's geht? Gibt 
es ein anderes Kriterium, dass man da ansetzen kann?

Vielen Dank

 Timm

[Jemand (Gast)]

Ich sehe keinen Grund, warum sich deine miniClass anders verhalten 
sollte als gewöhnliche POD Konstrukte, sie modifiziert ja nur ihren 
eigenen Zustand ohne Seiteneffekte.

Lock-Free bedeutet bei dieser Queue nur, dass enqueue und dequeue den 
internen Speicher oder Zustand nicht sperren müssen und die korrekte 
Funktion durch (einfache) atomare Operationen sichergestellt ist, 
dadurch gibt es aber die Enschränkung, dass es nur ein Enqueue-Thread 
und ein Dequeue-Thread zu einem gegebenen Zeitpunkt geben darf.

Timm R. schrieb:
> das Schicksal beschließt unabhängig von
> verstrichener Zeit, das miniClass Objekt erst in dem Moment fertig zu
> stellen, in dem ich es auch auslesen will.

Was meinst du mit fertigstellen? Der Zugriff auf ein Element in der 
Queue kann erst stattfinden, nachdem es konstruiert wurde, dafür sorgt 
die Queue.

[Jemand (Gast)]

Wenn du dich auf die Warnung des ThreadSanitizers beziehst: Die ist 
weitgehend unabhängig von irgendwelchen Timings, es müssen keine 
tatsächlichen Effekte eingetreten sein.

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Jemand schrieb:

> Was meinst du mit fertigstellen? Der Zugriff auf ein Element in der
> Queue kann erst stattfinden, nachdem es konstruiert wurde, dafür sorgt
> die Queue.

hmm, aber die Race Condition tritt doch auf, weil ich mit dem 
Lesezugriff für das dequeue den Schreibzugriff für das enqueue treffe?