Comment les compilateurs C ++ peuvent-ils prendre en charge C ++11 atomic, mais pas le modèle de mémoire C ++11

Question

En regardant Clang et g++ C++11 état de mise en œuvre, j'ai remarqué quelque chose d'étrange:
ils support de C++11 atomics, mais ils ne sont pas de support de C++11 modèle de mémoire.
J'étais sous l'impression que vous devez avoir C++11 modèle de mémoire à utiliser atomics. Alors, quelle est exactement la différence entre le support pour atomics et de la mémoire de modèle?
Le manque de modèle de mémoire de soutien juridique C++11 programmes qui utilisent l' std::atomic<T> arent seq-elle cohérente?

références:
http://clang.llvm.org/cxx_status.html
http://gcc.gnu.org/gcc-4.7/cxx0x_status.html

Answer 1

L'un des problèmes est la définition de l'emplacement de la mémoire", qui permet (et force le compilateur à l'appui) de verrouillage différents membres de structure par serrures différentes. Il y a une discussion à propos d'une RL problème causé par cette.

Fondamentalement, le problème est que le fait d'avoir un struct défini comme ceci:

struct x {
    long a;
    unsigned int b1;
    unsigned int b2:1;
};

le compilateur est libre de mettre en œuvre l'écriture d' b2 par écrasement b1 (et apparemment, à en juger par le rapport, il n'). Par conséquent, les deux champs doivent être verrouillé comme un. Cependant, comme une conséquence du C++11 modèle de mémoire, c'est interdit (enfin, pas vraiment interdit, mais le compilateur doit assurer simultanément des mises à jour b1 et b2 n'interfèrent pas; il pourrait le faire par le verrouillage ou l'AC-tion de chaque mise à jour, eh bien, la vie est difficile sur certaines architectures). Citant le rapport:

J'ai soulevé la question auprès de nos GCC gars et ils m'ont dit que: "C n' ne pas fournir une telle garantie, ni de manière fiable de verrouillage différents structure des champs avec des serrures différentes si elles partagent naturellement aligné mot-taille de la mémoire régions. Le C++11 mémoire de modèle à la garantir, mais ce n'est pas mis en œuvre, ni ne vous compiler le noyau avec un C++11 compilateur".

Sympa d'informations peut également être trouvé dans le wiki.

Answer 2

Je suppose que le "Manque de modèle de mémoire" dans ces cas, signifie simplement que les optimiseurs ont été écrits avant le C++11 modèle de mémoire a été publié, et pourrait effectuer maintenant invalide optimisations. Il est très difficile et prend du temps pour valider les optimisations contre le modèle de mémoire, c'est donc sans grande surprise que le clang/gcc équipes n'ai pas fini encore.

Le manque de modèle de mémoire de soutien juridique C++11 programmes qui utilisent std::atomic arent seq-elle cohérente?

Oui, c'est une possibilité. C'est encore pire: le compilateur peut introduire des données courses dans (selon le standard C++11) course-gratuit programmes, par exemple en introduisant spéculative écrit.

Par exemple, plusieurs compilateurs C++ utilisé pour effectuer cette optimisation:

for (p = q; p = p -> next; ++p) {
    if (p -> data > 0) ++count;
}

Pourrait obtenir optimisé en:

register int r1 = count;
for (p = q; p = p -> next; ++p) {
    if (p -> data > 0) ++r1;
}
count = r1;

Si tous p->data sont non-négatives, le code source d'origine n'a pas d'écrire count, mais l'optimisation de code ne. Cela peut introduire des données course dans une course-programme libre, de sorte que le C++11 spécification n'autorise pas de telles optimisations. Compilateurs existants ont maintenant à vérifier et ajuster si nécessaire) toutes les optimisations.

Voir la Simultanéité de la mémoire de modèle compilateur conséquences pour les détails.

Answer 3

Ce n'est pas tant qu'ils ne prennent pas en charge le modèle de mémoire, mais qu'ils ne prennent pas (encore) en charge l'API dans la norme pour interagir avec le modèle de mémoire. Cette API comprend un certain nombre de mutex.

Cependant, Clang et GCC ont été aussi sensibles aux threads que possible sans norme formelle depuis un certain temps. Vous n'avez pas à vous soucier des optimisations qui déplacent les choses du mauvais côté des opérations atomiques.