Discussion :

[Jean-Marc.Bourguet]

Dans un système, le CPU n'est pas le seul gadget pouvant avoir un accès direct à la mémoire...

Ma comprehension (d'apres entre autres des messages de John Mashey sur comp.arch relatant le contexte de l'introduction de volatile dans le langage C) c'est que volatile doit alors suffire, mais c'est a charge de l'utilisateur de ne le faire que sur des zones non cachees (et donc il faudrait que volatile introduise des barrieres sur Sparc puisqu'il n'y a pas moyen de regler le MMU pour qu'elles ne soient pas necessaires).

Mais ce qui est sur c'est qu'au mieux la semantique desiree de volatile est sous-specifiee, au pire elle n'est pas specifiable dans le modele d'execution utilise par les normes C et C++ pour specifier leur semantique.

[Montag]

Je ne comprend pas trop ce que vous entendez par "barrière d'optimisation".
Voir modèle mémoire de la JVM et les articles données en référence. Ils sont assez instructifs.
-W

Pour moi une barrière d'optimisation est une "barrière" qui empêche le compilateur de réordonner certains accès mémoire alors q'une barrière mémoire ("mémoire fence") agit au niveau du hardware.

Ceci étant dit, ce que j'ai dit dans mon post précédent est faux puisque apparemment (d'après les liens que tu as donnés) en Java volatile agit à la fois comme une barrière d'optimisation et comme une barrière mémoire.

[wiztricks]

Ma comprehension (d'apres entre autres des messages de
John Mashey sur comp.arch relatant le contexte de l'introduction de volatile dans le langage C) c'est que volatile doit alors suffire, mais c'est a charge de l'utilisateur de ne le faire que sur des zones non cachees (et donc il faudrait que volatile introduise des barrieres sur Sparc puisqu'il n'y a pas moyen de regler le MMU pour qu'elles ne soient pas necessaires).

Disons que le contexte dans lequel "volatile" a été initialement conçu pour dire au compilateur d'éviter certaines optimisations.
Bien que suffisant dans beaucoup de cas, cela ne rend pas compte des spécificités des architectures matérielles. Soit on laisse le programmeur s'en débrouiller, soit on fait comme Java, ie le langage propose un modèle mémoire indépendant de l'architecture.

Mais ce qui est sur c'est qu'au mieux la semantique desiree de volatile est sous-specifiee, au pire elle n'est pas specifiable dans le modele d'execution utilise par les normes C et C++ pour specifier leur sémantique.

Il y a eu pas mal de réflexions sur le sujet dans le cadre de C++0x. Mais j'ignore si cela a abouti à un "bon" compromis.
-W