Pourquoi les compilateurs ne fusionnent-ils pas les écritures atomiques redondantes de même valeur ?

Pourquoi les compilateurs évitent de fusionner les écritures atomiques redondantes

Introduction

Les compilateurs adhèrent souvent au " "comme si", leur permettant de réorganiser les opérations tant que le comportement observable reste cohérent. Cependant, dans le cas de magasins consécutifs dans une variable atomique de même valeur, tels que :

std::atomic<int> y(0);
void f() {
  auto order = std::memory_order_relaxed;
  y.store(1, order);
  y.store(1, order);
  y.store(1, order);
}

les compilateurs ont tendance à émettre les écritures séparément.

Limitations du C Norme

Si les normes C 11 et C 14 permettent techniquement de fusionner les trois magasins, elles ne garantissent pas qu'un observateur verra un jour la valeur intermédiaire de 2. Ainsi, optimiser en regroupant les magasins en une seule opération violerait l'intention de la norme d'autoriser toute commande valide.

Considérations du compilateur

Les compilateurs donnent la priorité à l'optimisation des performances plutôt qu'à la prévisibilité, ce qui conduit à des approches conservatrices. Malgré le caractère permissif de la norme, les compilateurs choisissent de ne pas fusionner les écritures atomiques pour éviter des problèmes potentiels, tels que les barres de progression qui restent bloquées lorsque plusieurs magasins sont incorrectement fusionnés.

Principe de la moindre surprise

Les programmeurs s'attendent généralement à ce que les magasins atomiques se produisent de manière séquentielle, chaque magasin étant exécuté comme écrit. Si un compilateur fusionnait ces opérations, cela pourrait introduire un comportement inattendu et violer le principe de la moindre surprise.

Améliorations à venir de l'API

Des discussions sont en cours dans les groupes de travail C. pour étendre l'API std::atomic avec des contrôles d'optimisation supplémentaires. Cela permettrait aux compilateurs d'optimiser les écritures atomiques dans les cas où cela est bénéfique sans violer les exigences de commande.

Solutions alternatives

En attendant, les programmeurs peuvent utiliser des variables atomiques volatiles pour empêcher les optimisations du magasin. Bien que cette méthode résolve principalement le problème de la barre de progression, ce n'est pas une solution idéale à long terme.

Conclusion

Les compilateurs ne fusionnent généralement pas les écritures atomiques consécutives avec le même valeur pour garantir la cohérence avec la norme C, éviter les problèmes de performances potentiels et adhérer au principe de la moindre surprise. Cependant, les futures améliorations de l'API pourraient permettre aux compilateurs de mettre en œuvre cette optimisation en toute sécurité à l'avenir.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!