Gibt es im "Latch" -Sample in N3600 eine Racebedingung?

Question

Vorgeschlagen für die Aufnahme in C++ 14 (alias C++ 1y) sind einige neue Thread-Synchronisations-Primitive: Latches und Barrieren. Der Vorschlag ist

• N3600: C++ Latches and Barriers
• N3666: C++ Latches and Barriers, revised

Es klingt wie eine gute Idee, und die Proben sehr Programmierer-freundlich aussehen. Leider denke ich, dass der Beispielcode undefiniertes Verhalten anspricht. Der Vorschlag sagt von latch::~latch():

Zerstört den Riegel. Wenn das Latch zerstört wird, während sich andere Threads in wait() befinden oder count_down() aufrufen, ist das Verhalten undefiniert.

Beachten Sie, dass es heißt "in wait()" und nicht, wie die Beschreibung von count_down() Nutzungen "in wait() blockiert".

Dann wurde die folgende Probe wird zur Verfügung gestellt:

Ein Beispiel des zweiten Anwendungsfall wird unten gezeigt. Wir müssen Daten laden und dann mit einer Anzahl von Threads verarbeiten. Das Laden der Daten ist I/O-gebunden, während das Starten von Threads und das Erstellen von Datenstrukturen CPU-gebunden ist. Indem diese parallel laufen, kann der Durchsatz erhöht werden.

void DoWork() 
{ 
    latch start_latch(1); 
    vector<thread*> workers; 
    for (int i = 0; i < NTHREADS; ++i) { 
     workers.push_back(new thread([&] { 
     // Initialize data structures. This is CPU bound. 
     ... 
     start_latch.wait(); 
     // perform work 
     ... 
     })); 
    } 
    // Load input data. This is I/O bound. 
    ... 
    // Threads can now start processing 
    start_latch.count_down(); 
} 

Gibt es kein Rennen Zustand zwischen den Faden Wachen und der Rückkehr von wait() und Zerstörung des Riegels, wenn es Spielraum läßt? Außerdem sind alle Objekte thread durchgesickert. Wenn der Scheduler nicht alle Worker-Threads ausführt, bevor count_down zurückgegeben wird, und das start_latch-Objekt den Gültigkeitsbereich verlässt, dann führt dies zu einem undefinierten Verhalten. Vermutlich besteht die Lösung darin, den Vektor und join() und delete alle Worker-Threads nach count_down zu wiederholen, aber bevor er zurückkehrt.

1. Gibt es ein Problem mit dem Beispielcode?
2. Stimmen Sie zu, dass ein Angebot ein vollständig korrektes Beispiel zeigen sollte, auch wenn die Aufgabe sehr einfach ist, damit die Prüfer sehen können, wie die Nutzungserfahrung aussehen wird?

---

Hinweis: Es scheint möglich, dass eine oder mehrere der Worker-Threads noch nicht warten begonnen, und deshalb wait() auf einem zerstörten Riegel nennen.

---

Update: Es gibt jetzt eine neue Version des Angebots, aber das repräsentative Beispiel ist unverändert.

Answer 1

Danke, dass Sie darauf hingewiesen haben. Ja, ich denke, dass der Beispielcode (der in seiner Verteidigung prägnant sein sollte) gebrochen ist. Es sollte wahrscheinlich warten, bis die Threads fertig sind.

Jede Implementierung, die das Blockieren von Threads in wait() erlaubt, wird mit ziemlicher Wahrscheinlichkeit eine Art von Bedingungsvariable enthalten und das Löschen des Latch, während ein Thread wait() noch nicht beendet hat, ist möglicherweise undefiniert.

Ich weiß nicht, ob es Zeit ist, das Papier zu aktualisieren, aber ich kann sicherstellen, dass die nächste Version behoben ist.

Alasdair