Je travaille sur une structure sans verrou avec un compilateur g ++. Il semble qu'avec le commutateur -o1, g ++ changera l'ordre d'exécution de mon code. Comment puis-je interdire l'optimisation de g ++ sur certaines parties de mon code tout en conservant l'optimisation à d'autres parties? Je sais que je peux le diviser en deux fichiers et les lier, mais c'est moche.Toute macro ou technique pour l'optimisation des pièces?
Vous pouvez utiliser un attribut de fonction "__attribute__ ((optimize 0))" pour définir l'optimisation pour une seule fonction ou "#pragma GCC optimize" pour un bloc de code. Ce ne sont que pour GCC 4.4, cependant, je pense - vérifiez votre manuel GCC. Si elles ne sont pas prises en charge, la séparation de la source est votre seule option. Je voudrais aussi dire, cependant, que si votre code échoue avec l'optimisation activée, il est très probable que votre code est juste faux, d'autant plus que vous essayez de faire quelque chose qui est fondamentalement très difficile. Le processeur effectuera potentiellement le réordonnancement sur votre code (dans les limites de la cohérence séquentielle) de sorte que toute réorganisation que vous obtenez avec GCC pourrait potentiellement se produire de toute façon.
Si vous trouvez que gcc modifie l'ordre d'exécution dans votre code, vous devriez envisager d'utiliser une barrière de mémoire. Ne supposez pas que les variables volatiles vous protégeront de ce problème. Ils s'assureront seulement que dans un seul thread, le comportement est ce que la langue garantit, et lira toujours les variables de leur emplacement de mémoire pour tenir compte des changements "invisibles" au code d'exécution. (Par exemple, les changements apportés à une variable par un gestionnaire de signal).
GCC prend en charge OpenMP depuis la version 4.2. Vous pouvez l'utiliser pour créer une barrière de mémoire avec une directive spéciale #pragma.
Un très bon aperçu sur le code de verrouillage est gratuit PDF par Herb Sutter et Andrei Alexandrescu: C++ and the Perils of Double-Checked Locking
Super lien, j'ai vraiment apprécié cet article. –
variables volatiles * pourrait * résoudre le problème en fonction des spécificités du problème. Ils garantissent un accès ordonné les uns aux autres, mais sans respect pour les données non volatiles. Les barrières de mémoire sont la réponse, mais existe-t-il une manière indépendante de la plate-forme pour en créer une dans GCC? Je pense que gcc considère que les blocs d'assemblage en ligne avec "m" spécifiés dans la liste de clobber comme des barrières complètes, mais autre que cela, je ne sais pas. –
droite, j'étais floue dans ma réponse. il ne réorganisera pas les lectures/écritures volatiles par rapport aux autres lectures/écritures volatiles dans le même thread. pas à travers les limites de fil. Je vais éditer pour être plus clair –
pourriez vous montrer la partie du code où l'ordre est changée? –