dans le contexte du message auquel tu réponds, ce n'est pas le compilateur, mais le CPU
Bah non justement. C'est le couple (compilateur, processeur), et deux peuvent réordonner. Si ce n'était qu'un problème de CPU, la gestion des atomics à l'ancienne à coups de bibliothèque suffirait. La nécessité d'introduire ces opérations dans le langage, c'est pour donner la visibilité au compilateur sur ces opérations et permettre non-seulement les barrières mémoire, mais aussi les barrières de compilation.
Par exemple, sur x86, le modèle mémoire est assez fort pour que la plupart des opérations atomiques puissent être compilées par un bête mov (regarde le code généré par un acquire ou un release si tu n'es pas convaincu. Perso je n'y croyais pas avant d'avoir vérifié ;-) ). La différence entre une opération atomique et une non-atomique est justement la barrière de compilation, pas la barrière mémoire qui n'est pas utile dans ce cas.
[^] # Re: Réordonnancement étrange...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche De la nécessité d’adopter les opérations atomiques C11 ?. Évalué à 2.
Bah non justement. C'est le couple (compilateur, processeur), et deux peuvent réordonner. Si ce n'était qu'un problème de CPU, la gestion des atomics à l'ancienne à coups de bibliothèque suffirait. La nécessité d'introduire ces opérations dans le langage, c'est pour donner la visibilité au compilateur sur ces opérations et permettre non-seulement les barrières mémoire, mais aussi les barrières de compilation.
Par exemple, sur x86, le modèle mémoire est assez fort pour que la plupart des opérations atomiques puissent être compilées par un bête
mov(regarde le code généré par un acquire ou un release si tu n'es pas convaincu. Perso je n'y croyais pas avant d'avoir vérifié ;-) ). La différence entre une opération atomique et une non-atomique est justement la barrière de compilation, pas la barrière mémoire qui n'est pas utile dans ce cas.