Concurrent C++ 11 - Quels toolchains peuvent être utilisés?

Question

J'utilise <thread> <atomic> <mutex> etc lourdement dans mon code, qui comprend plusieurs algorithmes sans verrou. Je vise (éventuellement) un environnement Linux. J'ai développé avec la version bêta de Visual Studio 2011, qui manque cruellement d'autres fonctionnalités C++ 11, semble être la seule chaîne d'outils qui implémente les fonctionnalités simultanées.

Voir c 11 ++ soutien ici:

• Clang 3+
• GCC 4.7
• MSVC 11

Maintenant, si les autres ne disposent pas simplement une bibliothèque contenant les C++ 11 fonctions simultanées, je peux facilement utiliser just::thread, cependant à la fois clang et gcc répondent "non" au modèle de mémoire C++ 11, ce qui semble au moins visuel. Je ne suis pas exactement sûr de l'effet que cela aurait - probablement l'optimisation du code libre d'effet secondaire, entre autres choses erronées.

Si pour l'instant j'évite complètement les builds optimisés et ne compile que les builds de débogage sans optimisations activées - est-il raisonnable d'utiliser la chaîne d'outils Clang ou GCC?

Answer 1

J'ai utilisé gcc-4.7 sur Linux 64 bits et Windows avec succès. std::thread etc fonctionne parfaitement sur linux même avec gcc-4.6.
Sur windows gcc-4.7 (mingw64) a quelques problèmes mineurs, des fuites de mémoire avec des destructeurs de std::condition_variable AFAIR.

Answer 2

GCC 4.7 status

C++ travail de modèle de mémoire est en cours et devrait être terminée dans la prochaine version GCC. GCC 4.7 a maintenant été publié, donc c'est ce que vous pouvez attendre de .

• Implémentation atomique complète pour les instructions sans verrou prises en charge. Toutes les opérations atomiques ont été implémentées avec les nouvelles variables internes __atomic , et la plupart des cibles reflètent le paramètre du modèle de mémoire dans le code qui est généré. Les optimisations ne bougeront pas la mémoire partagée opérations passées opérations atomiques, de sorte que les diverses relations sont honorées.
• Lorsque des instructions verrouillées ne sont pas disponibles (via le matériel ou la prise en charge du système d'exploitation), les opérations atomiques sont laissées en tant qu'appels de fonction pour être résolues par une bibliothèque. En raison des contraintes de temps et d'une API qui n'est pas finalisée, , aucun composant libatomique n'est fourni avec GCC 4.7. Ceci est facilement déterminé en rencontrant des symboles externes insatisfaits commençant par _ atomique *.
• Si un programme nécessite une assistance de bibliothèque, une seule implémentation d'exemple de fichier C est disponible pour être compilée et liée au programme client pour résoudre ces appels de fonction externe à l'aide d'une implémentation verrouillée. Télécharger l'exemple libatomic
• Les modèles C++ prennent entièrement en charge des objets de taille arbitraire, bien que le fichier libatomic.c mentionné précédemment puisse être requis pour satisfaire certaines classes définies par l'utilisateur . Si une classe correspond à la taille d'un type intégral sans verrouillage pris en charge, des routines sans verrouillage seront également utilisées.
• Les champs de bits ne sont pas compatibles avec le modèle de mémoire. C'est-à-dire qu'ils peuvent introduire des courses de données de chargement ou de stockage dues aux mots entiers lors de la lecture ou de l'écriture.
• Les optimisations n'ont pas été entièrement vérifiées pour la conformité, bien que certains travaux aient été effectués. Certaines optimisations peuvent introduire de nouvelles données races qui n'étaient pas présentes auparavant. Le nombre de cas connus est petit, et les tests de conformité n'est pas trivial. Si quelqu'un rencontre un cas où une optimisation introduit une nouvelle course de données, veuillez ouvrir un cas bugzilla pour qu'il puisse être adressé.

---

soutien à LLVM semble être plus long: http://llvm.org/releases/3.0/docs/Atomics.html

Il est difficile de dire à quel point cela est réellement utilisé dans clang bien. Il semble que <atomic> fonctionne essentiellement pour certains types. Je reçois des assertions de compilateur pour d'autres types disant que le type atomique était inattendu, ce qui donne un peu de confiance aux types avec lesquels il travaille.