Ma question est plus poussé, c'est "Est ce que le fait que GCC/Clang ne remplace pas cela par une boucle infinie est un comportement documenté/standard/… et si oui pourquoi ?".
Non, ce n'est pas standard, mais c'est plutôt une limite de l'optimisation faite par GCC.
Si ta variable n'est pas volatile, le compilateur peut tout à fait hoister la lecture.
Le problème c'est que si tu as une variable globale - notamment non statique - et que dans ta boucle tu fais:
variable = 0;
while (variable) {
foo(autre_variable);
…
}
et que GCC ne peut pas prouver que foo(autre_variable) ne modifie pas variable, il va forcer un reload.
Par contre si tu appelles une fonction pure, il y a des chances que GCC ne fasse pas le reload.
Si jamais il est fait référence à la variable running avant la boucle pour un appel de fonction ou autre, GCC génère tout de même le read, même sans volatile.
Essaie d'appeler une fonction static.
Ton volatile ne servira pas à grand chose : rien ne garanti que la lecture ne se fera pas dans un cache ou un write buffer pas flushé. cf. le lien "volatile considered harmfull" que j'ai posté dans un autre commentaire.
En pratique dans ce genre de boucle tu souvent toujours des syscalls/instructions qui vont provoquer une memfence (du genre un mutex ou opération atomique sur une autre variable). Sinon, en l'absence de telles instructions, en effet dans un cas simple comme au dessus ça ne suffit pas à le garantir.
Mais en pratique dès qu'un thread fait un appel système, context switch ou est schedulé sur un autre core, c'est équivalent à une memory barrier.
[^] # Re: Ai-je bien compris ?
Posté par neologix . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 3.
Non, ce n'est pas standard, mais c'est plutôt une limite de l'optimisation faite par GCC.
Si ta variable n'est pas volatile, le compilateur peut tout à fait hoister la lecture.
Le problème c'est que si tu as une variable globale - notamment non statique - et que dans ta boucle tu fais:
variable = 0;
while (variable) {
foo(autre_variable);
…
}
et que GCC ne peut pas prouver que foo(autre_variable) ne modifie pas variable, il va forcer un reload.
Par contre si tu appelles une fonction pure, il y a des chances que GCC ne fasse pas le reload.
Essaie d'appeler une fonction static.
En pratique dans ce genre de boucle tu souvent toujours des syscalls/instructions qui vont provoquer une memfence (du genre un mutex ou opération atomique sur une autre variable). Sinon, en l'absence de telles instructions, en effet dans un cas simple comme au dessus ça ne suffit pas à le garantir.
Mais en pratique dès qu'un thread fait un appel système, context switch ou est schedulé sur un autre core, c'est équivalent à une memory barrier.