Ich versuche, mich mit C ++ 11 Atomics vertraut zu machen, also habe ich versucht, eine Barriere-Klasse für Threads zu schreiben (bevor jemand sich darüber beschwert, dass er keine vorhandenen Klassen verwendet): Das ist mehr für das Lernen / Selbstverbessern als für irgendeinen wirklichen Bedarf ). Meine Klasse sieht grundsätzlich so aus:

Alle Mitglieder werden auf null initialisiert, mit Ausnahme von thread_count, das die entsprechende Anzahl enthält. Ich habe die Wartefunktion als

Wenn Sie jedoch versuchen, es mit zwei Threads zu verwenden ( thread_count ist 2), w \ u00e4hlt der erste Thread in die Wait-Schleife, aber der zweite Thread entriegelt die Barriere nicht (es scheint, dass es nicht einmal dazu kommt) int val = counter[idx].fetch_add(1); , aber ich bin mir nicht sicher, dass etwa Allerdings, wenn ich gcc Atom-Spezifika bin mit unter Verwendung volatile int anstatt std::atomic<int> und Schreiben wait wie folgt:.

es funktioniert gut. Aus meiner Sicht sollte es zwischen den beiden Versionen keine grundsätzlichen Unterschiede geben (mehr zu dem Punkt, wenn die Sekunde weniger wahrscheinlich funktionieren sollte). Welches der folgenden Szenarien gilt also?

1. Ich hatte Glück mit der zweiten Implementierung und mein Algorithmus ist Mist
2. Ich habe std::atomic nicht vollständig verstanden und es gibt ein Problem mit der ersten Variante (aber nicht der zweiten)
3. Es sollte funktionieren, aber die experimentelle Implementierung für C ++ 11-Bibliotheken ist nicht so ausgereift, wie ich gehofft habe

Für den Datensatz verwende ich 32bit mingw mit gcc 4.6.1

Der aufrufende Code sieht so aus:

Da mingw nicht <thread> headers jet verwendet, verwende ich eine selbstgeschriebene Version für das, was im Grunde die entsprechenden pthread-Funktionen umschließt (bevor jemand fragt: Ja, es funktioniert ohne die Barriere, also sollte es kein Problem sein mit die Verpackung) Irgendwelche Einsichten würden geschätzt werden.

edit: Erklärung für den Algorithmus, um es klarer zu machen:

• thread_count ist die Anzahl der Threads, die auf die Barriere warten sollen (wenn also thread_count Threads in der Barriere sind, können alle die Barriere verlassen).
• lock wird auf eins gesetzt, wenn der erste (oder ein beliebiger) Thread die Barriere erreicht.
• counter zählt, wie viele Threads innerhalb der Barriere liegen und wird für jeden Thread
einmal atomar inkrementiert
• if counter>=thread_count Alle Threads befinden sich innerhalb der Barriere, also werden Zähler und Sperre auf Null zurückgesetzt
• andernfalls wartet der Thread darauf, dass lock zu null wird
• in dem nächsten Einsatz der Barriere verschiedenen Variablen ( counter , lock ) verwendet, noch keine Probleme sicherzustellen, dass es, wenn Gewinde auf dem ersten Einsatz der Barriere warten (zB sie verdrängt worden war, als die Barriere aufgehoben)

edit2: Ich habe jetzt getestet es gcc 4.5.1 unter Linux verwenden, in denen beide Versionen scheinen gut zu funktionieren, was zu einem Problem mit mingw des std::atomic zu verweisen scheint, aber ich bin immer noch nicht ganz überzeugt, da ein Blick in das Verzeichnis <atomic> Header revaled, dass die meisten Funktionen einfach die entsprechende gcc-atomare Bedeutung nennen, da es eigentlich keinen Unterschied zwischen den beiden Versionen geben sollte