Quand utiliser volatile avec le multi threading?

Si il y a deux fils de l'accès à une variable globale, puis de nombreux tutoriels dire que la variable volatile pour empêcher le compilateur de la mise en cache de la variable dans un registre et ainsi de ne pas obtenir mis à jour correctement.
Cependant les deux fils à la fois de l'accès à une variable partagée est quelque chose qui demande de protection par l'intermédiaire d'un mutex n'est-ce pas?
Mais dans ce cas, entre le fil de verrouillage et de libérer le mutex le code est dans une section critique où seulement qu'un thread peut accéder à la variable, auquel cas la variable n'a pas besoin d'être volatile?

Donc qu'est-ce que l'utilisation et le but de volatiles dans un programme multi-threadé?

  • Dans certains cas, vous ne voulez pas/besoin d'une protection par le mutex.
  • Parfois, c'est bien d'avoir une condition de concurrence, parfois il ne l'est pas. Comment êtes-vous à l'aide de cette variable?
  • Un exemple de cas où il est "amende" pour avoir une course de, s'il vous plaît?
  • Va ici. Imaginez que vous avez un thread de travail qui est le traitement d'un certain nombre de tâches. Le thread de travail incrémente un compteur à chaque fois qu'il termine une tâche. Le maître thread lit régulièrement ce compteur et les mises à jour de l'utilisateur avec des nouvelles de l'avancement. Tant que le compteur est bien aligné pour éviter de déchirer il n'est pas nécessaire de synchroniser les accès. Bien qu'il y a une course, c'est bénin.
  • Il serait difficile d'en évaluer la sécurité d'un tel dispositif sans un examen complet de la code. Même si un examen a conclu que les écritures ont été atomique (douteuse) et entièrement écrit-via le cache (difficile à dire), je serais encore à rejeter ce que les "mauvais code". C'est safetey serait extrêmement ténue, et facilement brisée par la plus petite des modifications au code. Maintennance les programmeurs de briser cet appareil facilement, et les problèmes qui n'apparaissent pas dans les tests.
  • Le matériel sur lequel l'exécution de ce code garantit que alignés variables ne peuvent souffrir de la déchirure. Si le travailleur est à la mise à jour de n à n+1 que le lecteur lit, le lecteur ne se soucie pas de savoir si ils obtiennent n ou n+1. Pas de décisions importantes vont être prises, car il est uniquement utilisé pour la production de rapports d'avancement.
  • Je suppose que je ne sais pas ce que tu veux dire par "la déchirure."
  • re déchirure, je vous offre la suite de Joe Duffy: msdn.microsoft.com/en-us/magazine/cc817398.aspx
  • Wow, mur de texte. 🙂 Mais merci, je n'ai pas lu encore. Je le ferai quand je reçois une chance.
  • C'est toutes d'excellentes choses, mais le peu sur déchirement est seulement un ou deux paragraphes.
  • Get +23 question score, accepter -18 réponse. F**k la logique.
  • isvolatileusefulwiththreads.com (ou @DavidHeffernan, software.intel.com/en-us/blogs/2013/01/06/... est à lire absolument morceau sur "bénigne" données courses)
  • Quand utiliser: jamais.
  • par exemple, si c'est "bien" d'avoir une course" à Chaque fois que c'est bien d'utiliser un mutex. Ou atomique. À peu près tous les non trivial MT programmes inoffensifs conditions de course.

InformationsquelleAutor David Preston | 2010-12-29
  1. 151

    Court & réponse rapide: volatile est (presque) inutile pour la plate-forme agnostique, multithread de programmation d'application. Il ne fournit pas de synchronisation, il ne crée pas de la mémoire des clôtures, ni n'assure la commande de l'exécution des opérations. Il n'a pas à effectuer des opérations atomiques. Il n'est pas de rendre votre code comme par magie thread-safe. volatile peut-être le plus mal compris de la facilité dans l'ensemble de C++. Voir cette, cette et cette pour plus d'informations sur volatile

    D'autre part, volatile a quelques utilisation qui pourrait ne pas être si évident. Il peut être utilisé de la même façon, on pourrait utiliser const pour aider le compilateur vous montrer où vous pouvez faire une erreur dans l'accès à certaines ressources partagées dans un non-protégés façon. Cette utilisation est discutée par Alexandrescu dans cet article. Toutefois, c'est essentiellement l'aide de C++ type de système d'une manière qui est souvent considéré comme une machination et peut évoquer un Comportement Indéfini.

    volatile a été spécifiquement conçu pour être utilisé lors de l'interfaçage avec le matériel mappé en mémoire, les gestionnaires de signaux et le setjmp code machine instruction. Cela rend volatile directement applicables au niveau des systèmes de programmation, plutôt que la normale applications au niveau de la programmation.

    2003 de la Norme C++ ne permet pas de dire que volatile s'applique à tout type d'Acquérir ou de Libération de la sémantique sur les variables. En fait, la Norme est complètement silencieux sur toutes les questions de multithreading. Toutefois, les plates-formes spécifiques ne s'appliquent Acquérir et la Libération de la sémantique sur volatile variables.

    [Mise à jour pour le C++11]

    Le C++11 Est la Norme maintenant ne reconnaître le multithreading directement dans le modèle de mémoire et de la lanuage, et il offre des installations de bibliothèque de traiter avec elle en une plate-forme indépendant de la manière. Cependant, la sémantique de volatile n'ont toujours pas changé. volatile est pas encore un mécanisme de synchronisation. Bjarne Stroustrup dit dans TCPPPL4E:

    Ne pas utiliser volatile sauf dans les bas-niveau du code qui traite directement
    avec le matériel.

    Ne présumez pas volatile a une signification spéciale dans le modèle de mémoire. Il
    ne fait pas. Il n'est pas, comme dans certains, plus tard pour les langues-un
    mécanisme de synchronisation. Pour obtenir la synchronisation, utilisez atomic, un
    mutex, ou un condition_variable.

    [/Mise à jour de fin]

    Ci-dessus s'applique le C++ le langage lui-même, tel que défini par le Standard 2003 (et maintenant le 2011 Standard). Certains des plates-formes spécifiques, toutefois, ne l'ajout de fonctionnalités supplémentaires ou des restrictions à ce volatile n'. Par exemple, dans MSVC 2010 (au moins) d'Acquérir et de Libération de la sémantique ne s'appliquent à certaines opérations sur volatile variables. À partir de MSDN:

    Lors de l'optimisation, le compilateur doit maintenir la commande parmi les références
    la volatilité des objets ainsi que des références à d'autres objets globaux. Dans
    en particulier,

    Une écriture à un objet volatile (écriture volatile) a Communiqué sémantique; une
    référence à un mondial ou un objet statique qui se produit avant l'écriture d'un
    volatile objet dans la séquence d'instruction va se produire avant que
    écriture volatile dans le binaire compilé.

    Une lecture d'un volatile objet volatils (lire) a Acquérir sémantique; une
    référence à un mondial ou un objet statique qui se produit après une lecture de
    la mémoire volatile dans la séquence d'instruction se fera après que
    lecture volatile dans le binaire compilé.

    Cependant, vous pourriez prendre note du fait que si vous suivez le lien ci-dessus, il y a un débat dans les commentaires quant à savoir si ou de ne pas acquérir/libération de la sémantique fait s'appliquent dans ce cas.

    • +1 Très bons liens. La sémantique de volatile ne doit pas être confondu entre les langues, y compris ce qui pourrait être trouvé dans un dictionnaire 🙂 (Il est très stricte de la mémoire sémantique de modèle en Java, par exemple, mais c'est un différentes langage/environnement).
    • Certains compilateurs ne fournir une sémantique supplémentaire à la volatilité qui est utile pour le développement multithread, mais ce n'est certainement pas partie de la norme.
    • Une partie de moi veut downvote cela, parce que le ton condescendant de la réponse et le premier commentaire. "volatile est inutile" est semblable à "manuel de l'allocation de mémoire est inutile". Si vous pouvez écrire un programme multithread sans volatile c'est parce que vous juché sur les épaules de ceux qui ont utilisé la volatile à mettre en œuvre des bibliothèques de threading.
    • juste parce que quelque chose de défis à vos croyances n'est pas condescendant
    • Je pense que le premier commentaire disant "si vous downvote vous ne comprenez pas" touché mon interprétation de la tonalité. Autres que que je l'ai lu comme un message fort contre l'utilisation de volatile qui est probablement correcte pour la plupart des gens qui écrivent niveau de l'application du code.
    • non, lire sur ce volatile en fait ne en C++. Ce que @John a dit est correct à la fin de l'histoire. Il n'a rien à voir avec le code de l'application vs code de bibliothèque, ou "ordinaire" vs "comme dieu omniscient programmeurs" pour cette question. volatile est inutile et inutile pour la synchronisation entre les threads. Le filetage des bibliothèques ne peut pas être mis en œuvre en termes de volatile; il doit s'appuyer sur une plate-forme spécifique de détails, de toute façon, et quand vous comptez sur ceux-ci, vous n'avez plus besoin volatile.
    • il est inutile et inutile pour la synchronisation entre les threads" (qui est ce que vous avez dit) n'est pas la même chose que "volatile est inutile pour la programmation multithread" (qui est ce que Jean a dit dans la réponse). Vous êtes correct à 100%, mais je suis en désaccord avec Jean (partiellement) - volatile peut encore être utilisé pour la programmation multithread (pour un ensemble très limité de tâches)
    • par exemple, voir le dixième de réponse (par la "Patate") dans les commentaires ici, pour une utilisation légitime de la volatils: software.intel.com/en-us/blogs/2007/11/30/... (même si c'EST un peu x86 spécifiques comme les autres plates-formes peut besoin de cœurs de vider les données les uns des autres, ce qui volatils évidemment de ne pas le faire)
    • Donc, vous avez essentiellement dit "il est utile! ...en supposant que cela, et d'ignorer ceci et cela, et...". Tout peut être vrai si vous faites assez d'hypothèses; et vous avez certainement abandonné le C++ comme langage avec ceux-ci.
    • eh bien, vous n'avez jamais dit que c'était inutile pour tout et je n'ai jamais dit que vous avez dit que ce soit. Vous avez toujours dit que son inutile pour la programmation multithread, ce qui est ce que je suis au différend. Ses pas particulièrement utile, mais ce n'est pas tout à fait inutile non plus.
    • Tout ce qui est utile est utile uniquement en vertu d'un certain ensemble d'exigences ou de conditions. Volatile est utile pour la programmation multithread en vertu d'un ensemble strict de conditions (et, dans certains cas, peut-être même mieux (pour une définition de mieux) que d'autres solutions). Vous dites "en ignorant ce qui et..", mais le cas lorsque la volatilité est utile pour le multithreading ne l'ignore pas, quoi que ce soit. Vous avez fait quelque chose que je n'ai jamais prétendu. Oui, l'utilité de la volatilité est limité, mais il n'existe pas - mais nous pouvons tous convenir qu'il n'est PAS utile pour la synchronisation.
    • Mon point était volatile est un langage C++ concept, pas une mise en œuvre du concept. Pourtant, vous avez dit que c'était utile, car certains détails de mise en œuvre. Qui n'a pas d'incidence sur son utilité en C++.
    • compris
    • Je pense que vous devriez envisager d'ajouter à votre réponse que volatile est version&acquérir [sémantique sur Visual C++ ](msdn.microsoft.com/en-us/library/12a04hfd%28v=vs.80%29.aspx) (voir aussi ma réponse ici: stackoverflow.com/questions/6995310/...)
    • J'ai récemment fait une longue élaboratifs modifier pour cette réponse. J'ai inclus certains spécifiques à la plateforme de détails.
    • Je peux à peine penser à un monde réel exemple d'utilisation volatils dans les applications normales au niveau de la programmation, est-il un?
    • Qu'est-ce que "Windows 2010"?
    • Une faute de frappe.
    • Cela nécessite une mise à jour à la mention std::atomic<T>
    • le 20 janvier edition inclus mention de atomique et d'autres dispositifs.
    • "Ne pas utiliser volatile, sauf dans les bas-niveau du code qui traite directement avec le matériel." Fortement en désaccord. Volatile est utile de gestionnaires de signaux, pour certains cas de code multithread, pour le test... Il n'est tout simplement pas un remplacement pour atomics dans la plupart des cas.
    • Unix auto-pipe truc, c'est plus utile pour les gestionnaires de signaux de volatiles et permet beaucoup plus robuste code.

    InformationsquelleAutor John Dibling
  2. 29

    Volatile est parfois utile pour la raison suivante: ce code:

    /* global */ bool flag = false;

while (!flag) {}

    est optimisée par la gcc pour:

    if (!flag) { while (true) {} }

    Qui est manifestement inexact si l'indicateur est écrit par l'autre thread. Notez que sans cette optimisation du mécanisme de synchronisation fonctionne probablement (selon le code des autres certaines barrières de la mémoire peuvent être nécessaires) - il n'est pas nécessaire pour un mutex dans 1 producteur - 1 consommateur scénario.

    Sinon le mot clé volatile est trop bizarre pour être utilisable - il ne fournit pas de mémoire garanties de classement wrt à la fois volatile et non volatile accès et de ne pas fournir toutes les opérations atomiques - c'est à dire que vous n'obtenez pas l'aide du compilateur avec mot-clé volatile sauf désactivé registre de la mise en cache.

    • Si je me souviens bien, C++0x atomique, est destinée à faire correctement ce que beaucoup de gens croient (à tort) se fait par la volatilité.
    • Ouais. C'est drôle, j'ai ajouté une ligne de C++0x atomique installations, mais ensuite retiré car il ne semble pas liée à la question exacte 🙂 C++0x atomique est, comme il se devait en béton load/store sémantique à chaque accès, sont très utiles.
    • volatile n'empêche pas l'accès à la mémoire de réorganisation. volatile accède à ne pas être réorganisées à l'égard des uns et des autres, mais ils fournissent aucun garantie au sujet de la réorganisation à l'égard de non-volatile objets, et ainsi, ils sont fondamentalement inutile que les drapeaux ainsi.
    • Je pense que la plupart des "volatile est inutile" foule s'appuient sur le fait que de plus en plus probable d'un code tel que while (!global_flag) { sleep(1); } fonctionne sans volatile parce que leurs compilateurs ne pas regarder dans sleep() lors de l'optimisation et donc supposer que sleep() peut modifier global_flag et donc le bon code est produit pour les mauvaises raisons. Peut-être un exemple pertinent pourrait être construit avec LLVM lien-temps optimisations?
    • Mais ce code est à l'aide occupé attente, quelque chose qui doit être évitée.
    • Je pense que vous avez la tête en bas. Le "volatile est inutile" foule s'appuie sur le simple fait que volatile ne protège pas contre la réorganisation, ce qui signifie qu'il est tout à fait inutile pour la synchronisation. D'autres approches pourraient être tout aussi inutiles (comme vous le mentionnez, lien-temps d'optimisation de code pourrait permettre au compilateur de coup d'oeil dans le code de supposer que le compilateur le traiter comme une boîte noire), mais cela ne veut pas corriger les lacunes de volatile.
    • certaines utilisations de drapeaux ne nécessitent pas qu'ils ne sont pas réorganisées (bien que la plupart le font, alors il y a un très très niche cas d'utilisation où l'utilisation d'explosifs est parfaitement bien, il y a beaucoup de gens qui abusent de volatiles de manière non sécurisée)
    • nom d'une situation où la réorganisation n'est pas un problème. Le drapeau est utilisé pour indiquer qu'un événement a eu lieu, et qui ne fonctionne que si l'événement est en fait, s'est produite lorsque le drapeau est réglé. Qui d'autres cas, vous avez à l'esprit?
    • Voir l'article de l'Arche de Robinson (lié ailleurs sur cette page), 10 commentaire (par la "Patate"). Fondamentalement, la réorganisation ne modifie pas la logique du code. Posté le code utilise le drapeau pour annuler une tâche (plutôt que de donner le signal de la tâche est faite), donc il n'a pas d'importance si la tâche est annulée avant ou après le code (par exemple: while (work_left) { do_piece_of_work(); if (cancel) break;}, si l'annulation est réorganisée au sein de la boucle, la logique est toujours valide. J'avais un morceau de code qui fonctionnait de la même façon: si le thread principal veut mettre fin, il définit l'indicateur pour les autres threads, mais il n'est pas...
    • ...importe si les autres threads ne un supplément de quelques itérations de leur travail boucles avant de résilier, tant qu'il se produit dans un délai raisonnable après que le drapeau est réglé. Bien sûr, c'est la SEULE utilisation que je peux penser et sa plutôt de niche (et peut ne pas fonctionner sur les plates-formes où l'écriture d'une variable volatile ne pas faire le changement visible pour les autres fils, bien que sur au moins x86 et x86-64 cela fonctionne). Certes, je ne conseillerais à personne de le faire réellement que sans une très bonne raison, je dis juste qu'une déclaration générale comme "volatile n'est JAMAIS utile dans le code multithread" n'est pas correct à 100%.
    • Depuis que je suis à la recherche pour une bonne réponse que je pouvais lien vers pourquoi volatile est inutile, je ne peux pas laisser ces commentaires ici stand. Ce que Dan est dit ici ne fonctionne que pour les architectures x86 en raison de sa forte sous-jacente du modèle de mémoire. Ce qu'il propose ici est tout aussi brisé que tous les autres cas d'utilisation de la volatilité sur de nombreuses autres plates-formes (par exemple, il n'y a aucune garantie que vous ne lisez pas un état de la valeur à partir de la mémoire cache). Donc oui, si vous voulez un programme qui ne fonctionne pas seulement sous x86, la volatilité est vraiment jamais utile..
    • Mon résumé de tout cela est: (1.) il existe des exemples où la volatilité est correcte et utile pour le multithreading (@Dan exemple: utilisation d'un volatile bool pour arrêter un thread boucle. un autre exemple) (1.addendum) exemples où le volatile est correcte et utile pour le multithreading sont compilateur/dépendant de l'implémentation (un compilateur peut avoir atomique comme le comportement de la volatilité, tandis qu'un autre ne peut pas) ET dépendant du matériel (arm vs x86) (3.) la déclaration de "volatile n'est JAMAIS correct/utile dans le code multithread" est faux, car il existe au moins un contre-exemple
    • Il y a des beaucoup plates-formes où il est possible à moindre coût s'assurer que d'une écriture une écriture volatile-une fois que la variable éventuellement être vu sur tous les autres threads (en quelques secondes); en effet, l'optimisation peut être aidé si il y avait un qualificatif qui ont été plus faibles qu' volatile ainsi qu'un compilateur serait libre pour optimiser un délimitée nombre de tentatives d'accès [par exemple, si un compilateur se déroule une boucle de 8 fois, il aurait seulement pour vérifier la variable une fois dans le déroulé de la boucle, plutôt que de vérifier huit fois]. La surcharge imposée par un mécanisme de relâchement de la sémantique...
    • ...pourrait être beaucoup moins que ce qui serait nécessaire lors de l'utilisation d'un mécanisme de plus en plus rigide de la sémantique.
    • ce qui est exactement ce que std::atomique avec les modèles de mémoire faible que l'acquisition/diffusion.
    • Si vous aussi vous pensez que "faisant référence à un passé la fin d'un tableau" n'est pas toujours à tort, car il y a un exemple où il "travaille"? Ce n'est pas comment c travaux particulièrement dangereux de penser que si la simultanéité est impliqué.
    • si par ", faisant référence à un passé la fin d'un tableau" tu veux dire "point un passé la fin d'un tableau", alors vous êtes bâclée avec la terminologie en tant que ne pas de référence, ainsi que la mémoire des points.
    • Êtes-vous juste en coupant les cheveux en quatre ou vraiment confus? J'aurais pensé à tout programmeur C++ serait de savoir que l'accès à la mémoire en dehors d'un tableau est un comportement indéfini, mais fonctionne encore assez souvent - ce qui est le point de l'ensemble de l'argument là. Mais oui j'ai perdu "de mémoire" il y et non, je ne voulais pas dire pointant vers un passé la fin d'un tableau, parce que ce n'est pas un comportement indéfini.
    • Non, sincèrement, je ne sais pas si vous signifie pointant vers quand vous avez dit référencement - je ne considère pas ça tatillonne à point (sic!) lorsque ces deux conditions sont mal utilisés, car ils sont entièrement différents. Maintenant que vous avez précisé que vous signifiait qu'un accès à la mémoire par référencement "un passé la fin de tableau" pouvez apparemment réussir, j'ai parfaitement comprendre votre relevé de compte.
    • Juste pour préciser pourquoi j'ai répondu à la première place; vous avez écrit "j'aurais pensé à tout programmeur C++ serait de savoir que l'accès à la mémoire en dehors d'un tableau est un comportement indéfini", mais je dirais que la grande majorité des développeurs C++ ne pas savoir ce que UB moyens et ne pas connaître la différence entre point et référence. Que la majorité est comme la matière noire, et peu susceptible d'être trouvé sur AFIN de, des conférences ou la lecture C++ blogs - ils sont encore la majorité.

    InformationsquelleAutor zeuxcg
  3. 0

    Vous avez besoin volatils et, éventuellement, de verrouillage.

    volatils raconte l'optimiseur que la valeur peut changer de manière asynchrone, donc 

    volatile bool flag = false;

while (!flag) {
    /*do something*/
}

    va lire drapeau à chaque fois autour de la boucle.

    Si vous activez l'optimisation off ou faire de chaque variable volatile d'un programme se comporte de la même, mais plus lent. volatile signifie simplement " je sais que vous venez juste de le lire et de savoir ce qu'il dit, mais si je dis le lire, puis de le lire.

    De verrouillage est une partie du programme. Donc ,en passant, si vous êtes à la mise en œuvre de sémaphores puis, entre autres choses, ils doivent être volatile. (N'essayez pas, c'est difficile, aura probablement besoin d'un peu d'assembleur ou le nouveau atomique choses, et ça a déjà été fait.)

    • Mais n'est-ce pas, et l'exemple même dans l'autre réponse, occupé attente et donc quelque chose qui doit être évitée? Si c'est un exemple artificiel, existe-il des exemples concrets qui ne sont pas inventés?
    • Ok oui. Vous avez vraiment besoin de faire quelque chose dans les accolades (je vais éditer l'article). Occupé attente est en général une mauvaise idée. Vous pouvez peut-être le traitement de quelque chose (une liste) jusqu'à ce qu'un autre thread signaux de vous arrêter. Sans le valatile il continuera toujours, et pour cet exemple, aucun verrouillage n'est nécessaire, bool est atomique.
    • Occupé attente est parfois une bonne solution. En particulier, si vous pensez que vous n'avez qu'à attendre pour un couple de cycles d'horloge, il porte beaucoup moins de frais généraux que le beaucoup plus lourds approche de suspendre le fil. Bien sûr, comme je l'ai mentionné dans d'autres commentaires, des exemples comme celui-ci sont erronées, car ils supposent que les lectures/écritures sur le drapeau de ne pas être réorganisée avec respect pour le code qu'il protège, et aucune garantie n'est donnée, et donc, volatile n'est pas vraiment utile, même dans ce cas. Mais occupé attente est parfois utile de la technique.
    • ma compréhension des choses, c'est que la volatilité indique au compilateur que la variable peut être lu/écrit de façon asynchrone sur le programme (par un autre thread ou mon matériel), il est censé donner la sémantique de la “si je dis de lire ou d'écrire puis lire ou d'écrire, et de le faire quand je te dis de faire.”. Si le CPU est ré-ordonnancement d'instructions qui modifient ces sémantique, alors le compilateur a vaincre cette optimisation ainsi. Ai-je raté quelque chose.
    • Oui et non. La première moitié est correct. Mais cela signifie seulement que le CPU et le compilateur ne sont pas autorisés à réorganiser variables à l'égard des uns et des autres. Si je lis un volatile de la variable A, et puis lire un volatile de la variable B, alors le compilateur doit émettre le code qui est garanti (même avec un CPU réorganisation) de lire Un avant b, Mais il ne donne aucune garantie à propos de tous les non-volatile de la variable d'accès. Ils peuvent être réorganisés autour de votre volatile de lecture/écriture de l'amende juste. Donc, sauf si vous faites tous variable dans votre programme volatile, il ne vous donnera la garantie de vous êtes intéressé à
    • Ce n'est pas vrai. Il n'est pas nécessaire que volatile empêcher CPU réorganisation et sur la plupart des plateformes modernes, il n'est pas réellement le faire.
    • Ne vous rendez-vous autour de poster des choses fausses à propos de volatile? Avez-vous une Norme autre que ces personnes? stackoverflow.com/questions/2535148/...
    • Lire les commentaires pour les deux réponses qui semblent être en désaccord avec moi et vous verrez qu'ils ne le font pas. Vous pas trouver accède à volatiles émettant des barrières de la mémoire, de sorte que la réorganisation est pas empêché.
    • Nous entendons la réorganisation des lectures/écritures de volatile, qui est la garantie de ne pas se produire - pas de réorganisation de tout dit en lecture/écriture par rapport à d'autres états (si oui ou non ils sont également volatile), qui est autorisé à se produire. Est ce que tu veux dire?
    • Encore une fois, vous verrez que presque tous les compilateur, lit et écrit à volatile variables ne pas émettent les barrières de la mémoire, même sur les plates-formes qui en ont besoin pour prévenir les lectures et les écritures de réorganisation et/ou fusionné. Essayez-la. (Êtes-vous d'accord que le CPU peut fusionner écrit à la mémoire ordinaire? Voyez-vous le compilateur fait rien pour l'arrêter quand deux écritures se produisent à la même volatile? Qu'en est écrit à deux adjacents volatile shorts, ou d'un "ABA" écrire pour eux? Voyez-vous quelque chose émis pour arrêter la combinaison d'écriture?)
    • vous acceptez que le CPU peut fusionner les écritures ordinaires de la mémoire?" Qui s'en soucie?
    • Eh bien, parce que si on peut fusionner deux écritures, qu'il ne peut pas préserver la commande d'entre eux. Le point est qu'il n'y a absolument aucune restriction sur les Processeurs de la capacité de réorganiser, de modifier, de fusionner ou de l'écrit. Rien n'impose aucune restriction de ce type et réelle Processeurs faire.
    • Ne devrait pas le compilateur C, question des limites des instructions entre les volatiles de lecture/écriture, pour s'assurer que la volatilité est à l'honneur?, Ou il y a des Processeurs qui ne permettent pas de volatiles pour être mis en œuvre?
    • Quelle est la définition de "fusionner deux écritures"?
    • Le code dit de faire deux ou trois écritures et le CPU au lieu de cela un ou deux. Par exemple, vous ne i=1; j=2; k=3; et le CPU ne i=1; k=3; en une seule opération atomique. Rien n'empêche un CPU en faisant cela, même si i, j, et k sont volatile et réel Processeurs faire. De processeurs peut même optimiser hors écrit à volatiles du monde réel et les Processeurs de faire ça. Donc i=1; j=2; i=3; peut entraîner la i=1; écrire arriver optimisé, encore une fois, même si i est volatile. C'est pourquoi de nombreux Processeurs ont de la mémoire de la barrière des opérations et volatile ne les utilise pas, ni est-il tenu de le faire.
    • En effet avec toutes les variables commençant par 0, si i=1; j=2; i=3; est transformé en j=2; i=3; qui briserait un autre thread attend (à tort) que j==2 ne peut se faire que si i>0.

    InformationsquelleAutor ctrl-alt-delor
  4. -2
    #include <iostream>
#include <thread>
#include <unistd.h>
using namespace std;

bool checkValue = false;

int main()
{
    std::thread writer([&](){
            sleep(2);
            checkValue = true;
            std::cout << "Value of checkValue set to " << checkValue << std::endl;
        });

    std::thread reader([&](){
            while(!checkValue);
        });

    writer.join();
    reader.join();
}

    Une fois un intervieweur qui croyait également que la volatilité est inutile d'argumenter avec moi que l'Optimisation ne cause pas de questions et se référant à différents cœurs à la séparation des lignes de cache et de tout ce qui (ne comprenais pas vraiment ce qu'il était exactement se référant à l'). Mais ce morceau de code lors de la compilation avec-O3 sur g++ g++ -O3 thread.cpp -lpthread), il montre un comportement indéterminé. En gros, si la valeur est avant tout vérifier qu'il fonctionne bien et si pas, il va dans une boucle sans prendre la peine d'aller chercher la valeur (ce qui a réellement changé par l'autre thread). Fondamentalement, je crois que la valeur de checkValue n'obtient récupérée à la fois dans le registre et n'est jamais vérifié de nouveau sous le plus haut niveau de l'optimisation. Si sa valeur true avant de le chercher, il fonctionne très bien et si pas, il va dans une boucle. S'il vous plaît corrigez-moi si me trompe.

    • Qu'est-ce que avez à faire avec volatile? Oui, ce code est UB-mais c'est UB avec volatile ainsi.
    InformationsquelleAutor Anu Siril