Ich verwende <thread> <atomic> <mutex> etc stark in meinem Code, der mehrere Lock-Free-Algorithmen enthält. Ich ziele (schließlich) auf eine Linux-Umgebung. Ich habe mit der Beta von Visual Studio 2011 entwickelt, die, obwohl sie fürchterlich in anderen C ++ 11-Funktionen fehlt, die einzige Toolchain zu sein scheint, die die parallelen Funktionen implementiert.
Siehe c ++ 11 Unterstützung hier:
Wenn nun die anderen einfach keine Bibliothek mit den C ++ 11-Begleitfunktionen haben, kann ich einfach just :: thread verwenden. Jedoch antworten sowohl clang als auch gcc "nein" auf das C ++ 11-Speichermodell, was zumindest Visual C ++ zu unterstützen scheint. Ich bin mir nicht ganz sicher, was die Wirkung davon wäre - wahrscheinlich weg von scheinbar nebenwirkungsfreiem Code unter anderen fehlerhaften Dingen zu optimieren.
Wenn ich jetzt vollständig optimierte Builds vermeide und nur Debug-Builds kompiliere, ohne dass Optimierungen aktiviert sind - ist es sinnvoll, die Clang- oder GCC-Toolchain zu verwenden?
Die C ++ - Speichermodell-Arbeit ist noch nicht abgeschlossen und soll in Kürze fertiggestellt werden nächste GCC-Veröffentlichung. GCC 4.7 wurde jetzt veröffentlicht, also ist das was du kann davon erwarten.
- Vollständige atomare Implementierung für unterstützte lockfreie Anweisungen. Alle atomaren Operationen wurden mit dem neuen __atomic implementiert Buildins, und die meisten Ziele spiegeln den Speichermodellparameter in der Code, der generiert wird. Optimierungen verschieben den gemeinsamen Speicher nicht Operationen vorbei an atomaren Operationen, so dass die verschiedenen passiert Beziehungen werden geehrt.
- Wenn sperrfreie Anweisungen nicht verfügbar sind (entweder über die Hardware- oder Betriebssystemunterstützung), bleiben atomare Operationen als Funktionsaufrufe übrig von einer Bibliothek gelöst werden. Aufgrund von Zeitbeschränkungen und einer API, die ist noch nicht abgeschlossen, es gibt keine libatomic mit GCC 4.7. Das ist leicht durch unbefriedigte externe Symbole festgestellt werden beginnend mit _ atomar *.
- Sollte ein Programm Bibliothekshilfe benötigen, steht eine einzige C - Datei - Beispielimplementierung zur Verfügung, die kompiliert und mit der Datenbank verknüpft werden kann Client-Programm, um diese externen Funktionsaufrufe mit einem locked aufzulösen Implementierung. Laden Sie das Beispiel libatomic
herunter- C ++ - Vorlagen unterstützen Objekte beliebiger Größe vollständig, obwohl die zuvor erwähnte Datei libatomic.c möglicherweise einige Anforderungen erfüllen muss benutzerdefinierte Klassen. Wenn eine Klasse der gleichen Größe zugeordnet ist wie eine unterstützte Lock-Free-Integral-Typ, dann werden auch Lock-Free-Routinen verwendet.
- Bitfelder sind nicht mit dem Speichermodell kompatibel. Das heißt, dass sie Datenrennen aufgrund des ganzen Wortes laden oder speichern können Zugriff beim Lesen oder Schreiben.
- Die Optimierungen wurden noch nicht vollständig auf Einhaltung überprüft, obwohl einige Arbeiten bereits durchgeführt wurden. Einige Optimierungen können neue Daten enthalten Rassen, die vorher nicht anwesend waren. Die Anzahl der bekannten Fälle ist klein, und das Testen auf die Einhaltung ist nicht trivial. Wenn jemand trifft Wenn eine Optimierung ein neues Datenrennen einführt, öffnen Sie bitte ein Bugzilla-Fall dafür, damit es angesprochen werden kann.
Unterstützung in LLVM scheint weiter zu sein: Ссылка
Es ist schwer zu sagen, in welchem Maße dies tatsächlich beim Klirren verwendet wird. Es scheint, dass <atomic> grundsätzlich für einige Typen funktioniert. Ich erhalte Compiler-Assertionen für andere Typen, die sagen, dass der atomare Typ unerwartet ist, was ein gewisses Vertrauen in die Typen gibt, mit denen er arbeitet.
Ich habe gcc-4.7 auf 64-Bit-Linux und Windows mit Erfolg verwendet. std::thread usw. funktioniert auch mit gcc-4.6 perfekt auf Linux.
Unter Windows hat gcc-4.7 (mingw64) einige kleinere Probleme, Speicherlecks mit Destruktoren von std::condition_variable AFAIR.
Tags und Links c++ multithreading c++11 synchronization lock-free