Pourquoi utiliser `memory_order_seq_cst` pour définir un indicateur d'arrêt vérifié avec `memory_order_relaxed` ?

Pourquoi utiliser memory_order_seq_cst pour définir le drapeau d'arrêt s'il est coché avec memory_order_relaxed ?

Dans sa présentation sur les "armes atomiques<>", Herb Sutter présente utilisation de variables atomiques, y compris un scénario impliquant :

• Thread principal générant des threads de travail

• Les travailleurs vérifiant un indicateur d'arrêt :

  while (!stop.load(std::memory_order_relaxed))
  {
    // Perform tasks
  }

  Copier après la connexion
• Le thread principal définit finalement l'arrêt sur true en utilisant memory_order_seq_cst.

Sutter affirme qu'en utilisant memory_order_relaxed pour vérifier l'indicateur est acceptable en raison de l'impact minimal sur le délai d'arrêt des threads. Cependant, la raison de l'utilisation de memory_order_seq_cst pour définir l'indicateur d'arrêt reste floue.

Analyse :

mo_relaxed est suffisant pour le chargement et le stockage de l'indicateur d'arrêt :

Il n'y a aucun avantage significatif en matière de latence à utiliser des ordres de mémoire plus forts, même si le la latence d'observation des changements dans les indicateurs stop ou keep_running est cruciale.

On ne sait pas pourquoi Sutter déconseille les opérations détendues en magasin. Cependant, la norme ISO C ne précise pas le délai de visibilité du magasin ni les facteurs qui l'affectent. Les implémentations ne sont obligatoires que pour garantir la visibilité sur une période finie.

Latence inter-thread et implémentation :

La latence inter-thread est principalement déterminée par l'implémentation. Les implémentations C du monde réel exploitent les mécanismes de cohérence du cache matériel, ce qui entraîne généralement une faible latence (des dizaines de nanosecondes) pour la visibilité du magasin.

Ni seq_cst ni les commandes de mémoire assouplies n'accélèrent la visibilité du magasin ; ils contrôlent simplement le comportement des opérations ultérieures par rapport au magasin ou à la charge. Des ordres plus forts n'accélèrent pas les événements mais retardent les autres opérations jusqu'à ce que l'ordre spécifié soit maintenu.

Visibilité détendue et cohérence du cache matériel :

Sur du matériel réel avec cohérence de cache, mémoire les commandes n'améliorent pas le timing de visibilité du magasin ; ils gèrent uniquement la capacité des opérations ultérieures à devenir visibles à l'échelle mondiale avant l'engagement du magasin.

Avantages de l'ordre de mémoire détendu pour Stop Flag :

Les principaux avantages de l'ordre de mémoire détendu pour vérifier l'indicateur d'arrêt sont :

• Parallélisme accru à travers les itérations de boucle lorsque le résultat du chargement est false.
• Évitement de l'exécution d'instructions inutiles, en particulier sur les ISA où les charges d'acquisition ou de seq_cst nécessitent des instructions supplémentaires (par exemple, ARMv7 dmb ish).

Conclusion :

Dans ce scénario, memory_order_relaxed est approprié à la fois pour charger et stocker l'indicateur d'arrêt. memory_order_seq_cst n'est pas nécessaire pour améliorer le timing de visibilité du magasin. Au lieu de cela, il est utilisé pour appliquer l'ordre souhaité des opérations ultérieures et éviter les problèmes liés aux écritures simultanées.

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!