Variables volatiles en C 11

L'introduction d'un modèle de machine multithread dans la norme C 11 soulève des questions sur le comportement des variables volatiles. variables, qui ont traditionnellement été utilisées pour empêcher une optimisation qui pourrait entraîner un comportement indéfini dans des environnements concurrents.

Dans C 98/03, le manque de reconnaissance du multithread dans le modèle de mémoire signifiait que le compilateur pouvait optimiser la lecture d'une variable volatile, conduisant au tristement célèbre exemple d'une boucle while sans fin attendant qu'une variable change de valeur.

Cependant, le modèle de mémoire C 11 reconnaît la possibilité d'un accès simultané aux variables. Cela signifie-t-il que volatile est désormais obsolète ?

Optimisations du compilateur et comportement non défini

La réponse réside dans la nature nuancée du modèle de mémoire C 11. Bien qu'il reconnaisse le multithreading, il n'élimine pas la possibilité d'un comportement indéfini lors de l'accès à des variables sans synchronisation appropriée. Même dans un environnement multithread, l'accès non atomique aux variables partagées reste indéfini.

volatile int x;
void func() {
x = 0;
while (x = = 0) {}
}

Par conséquent, dans notre exemple de code, le compilateur est toujours libre d'optimiser la lecture de x dans la boucle while, ce qui entraîne un comportement indéfini. La volatilité n'affecte que les accès à la mémoire, pas le comportement des threads.

Barrières de mémoire et intégrité des threads

L'intégrité des threads nécessite des mécanismes de synchronisation appropriés pour garantir la visibilité des écritures d'un thread à un autre. . Le modèle de mémoire C 11 définit spécifiquement quand et comment les écritures deviennent visibles pour les autres threads. volatile ne répond pas à cette exigence.

volatile garantit que le compilateur ne peut pas optimiser les lectures de mémoire à partir d'une variable, mais il ne fournit aucune garantie quant à la visibilité des threads. Des barrières de mémoire, émises par des constructions de synchronisation telles que des verrous ou des opérations atomiques, sont nécessaires pour garantir que les écritures sont synchronisées entre les cœurs.

Conclusions

En C 11, volatile reste pertinent pour empêcher les optimisations qui pourraient conduire à des accès mémoire incorrects. Cependant, cela n’est pas suffisant pour la programmation multithread. Des mécanismes de synchronisation appropriés sont toujours nécessaires pour garantir l'intégrité des threads et un comportement défini dans des environnements concurrents.