Version imprimable
Hello,
Je viens de lire un intéressant article d'Andrei Alexandrescu, au sujet de l'utilisation du mot-clef volatile.
Il propose l'utilisation d'une classe conteneur, un peu sur le principe des pointeurs intelligents.
Je me demandais si cela avait déjà été mis en œuvre dans Boost, ou si je dois coder moi-même en fonction des propos d'Andrei.
Merci.
Si j'ai bonne memoire, cet article avait declanche un beau thread sur comp.lang.c++.moderated ou il avait fini par reconnaitre que volatile ne servait a rien d'autre en multithread qu'a masquer temporairement certaines erreurs sur certaines architectures.Citation:
Envoyé par oodini
Voir aussi les documents preparatoires a C++0X qui discuttent quelque part de la semantique actuelle de volatile (a part pour les signaux et longjmp, rien de precis; historiquement concu pour traiter les IO mappees en memoire, de nos jours il faut au minimum une collaboration de l'OS pour que ca ait du sens, et encore certains compilateurs ne generent pas ce qu'il faut meme dans ce cas -- verifie pour Sparc) et d'une possible extension au multithread mais cette piste n'a pas ete suivie.
Lire: Thread Cannot be Implemented as a Library
Sur Linux, boost implemente les threads au dessus la de la librarie POSIX. Les sections critiques sont déclarées via des primitives telles que pthread_mutex_lock() qui incluent des primitives hardwares (memory barrier) interdisant les optimisations d'accès mémoires pouvant induire des problèmes de synchronisation.
Si la manipulation des variables globales (partagées par plusieurs threads) sont encapsulées par ces primitives, "volatile" est, à priori, inutile.
voir aussi: A Memory model for C++: FAQ qui explique pourquoi "volatile" est insuffisant.
-W
Et si on utilise les mutex de boost, je suppose donc qu'on peut également se passer de volatile ?
volatile n'est jamais necessaire en multithread -- il masque simplement parfois des problemes qui peuvent resurgir dans d'autres configurations.Citation:
Envoyé par oodini
Je vois déjà quelques petits morceaux de HS.
Dans l'article, volatile n'était pas utilisé pour ses propriétés rêvées ou propriétaires, mais pour tagguer des fonctions et dire: "cette fonction n'est pas thread-safe et ne sera accédée que depuis un seul thread à la fois", et "cette fonctions est thread-safe". En gros, c'est un pas vers de la vérification statique de code.
Que cela marche ou pas, je n'ai pas assez creusé les échanges sur clc++m pour le dire.
Dans le même ordre idée, voir l'article récent de Scott Meyers sur artima, où il va bien plus loin dans l'idée. Sa démonstration est intéressante, mais malheureusement inapplicable.
Pour repartir dans l'HS, il semblerait qu'avec des moutures récentes de VC, volatile puisse être utilisé pour mettre en œuvre des singletons pouvant être construits paresseusement depuis un contexte multi-threadé -- là où le double lock-pattern (à base de mutex) a échoué.
Il me semblait qu'il utilisait volatile simplement pour créer une type différent sur lequel une surcharge était possible, pas pour de supposées (mais fausses) vertus intrinsèques en terme de multithread, mais que n'importe quel autre décorateur de type peu employé aurait pu servir à la même chose. Ou alors je confond d'article ?Citation:
Envoyé par Jean-Marc.Bourguet
C'est peut-etre moi qui confond. Il y a bien eu aussi un article dans ce genre -- et c'est bien le style d'Andrei -- mais il me semble plus recemment (je n'ai guere fait plus que lire la date -- 2001). C'est pas impossible non plus qu'il y a eu une redecouverte de l'article plus recemment qui induise ma perception temporelle en erreur.Citation:
Envoyé par JolyLoic
Pour faire simple volatile (ici) est une instruction donnée au compilo pour lui dire: "Attention, cette variable pourra être modifiée par un autre "thread", si tu en stockes la valeur dans un registre n'oublie pas d'en rafraîchir le contenu depuis la mémoire avant chaque utilisation!".
Nous ne parlons pas ici de synchronisation de "threads" mais de mise à jour entre ce qui est "dans" le CPU et ce qui est "dans" la mémoire.
Indirectement, cela garantit la cohérence entre ce qui sera récupéré par deux threads accédant à la mémoire.
Le modèle mémoire des architectures CPU de type CISC étaient cohérentes avec celui des langages de programmation à quelques exceptions près (dont celles ci). L'univers a changé, il y a plus d'une quinzaine d'année avec des architectures RISC dites multi-scalaires (et est instable depuis(*)).
Pour essayer d'utiliser les capacités de calculs de ces bêtes, on pourra non seulement exécuter les instructions dans le désordre (out of order OOO) mais aussi optimiser les écritures du cache vers la mémoire (lazy write).
=> Finie la correspondance entre ce qu'on a écrit dans un langage haut niveau et ce qui sera exécuté par la machine!
Impossible d'en rendre compte avec un modèle mémoire réduit aux entités { registres, mémoire }. De plus, s'il y a problème, c'est seulement pour les programmes multi-threads (ou le système d'exploitation).
Point de salut en dehors de l'écriture ou de l'utilisation de primitives adaptées au processeur (et si possible portables) telle que POSIX threads ou TBB.
(*) instable
A la fin des années 90 (même pas une dizaine après leur adoption), monter en fréquence a posé d'énormes soucis côté OOO.
Utiliser au mieux les capacités signifie que l'algorithme OOO est capable de jouer au bongo avec de plus en plus d'instructions en cours (allonger le pipeline).
Ce qui impose un minimum de synchronisation incompatible avec la montée en fréquence: soit on a des bugs, soit on bride la bête!
Et trois écoles on vu le jour:
- Itanium : l'intelligence est complètement dans le compilo, le processeur déroule le ruban d'instruction qu'on lui soumet,
- Power6 : cadencé vite mais sans OOO
- Sparc (repris depuis par AMD et Intel) : sacrifions la capacité brute mais utilisons la densité pour multiplier le nombre de cœurs.
Note: Au delà les querelles techniques et du récent habillage "green IT" des multi-coeurs, Sun et IBM ont d'abord décidé d'utiliser les budgets transistor pour répondre aux besoins de leurs clients (base installée).
Ce qui est somme toute raisonnable.
- W
Ce n'est pas que cela ne soit pas intéressant, mais c'est HS p/r à la question de l'OP où volatile est utilisé comme indicateur sur les fonctions (et non des données) pour faire de la vérification statique de code.
Sauf que comme ça fait pas de memory barriers ça marche qu'en mono-cœur...Citation:
Pour faire simple volatile (ici) est une instruction donnée au compilo pour lui dire: "Attention, cette variable pourra être modifiée par un autre "thread", si tu en stockes la valeur dans un registre n'oublie pas d'en rafraîchir le contenu depuis la mémoire avant chaque utilisation!".
J'ai relu l'article mentionné mais il ne semble pas aller aussi loin que vous le proposez.Citation:
Envoyé par Luc Hermitte
- W
C'est bien pire: "ca ne fait pas de "memory barrier" donc çà peut faire n'importe quoi même sur un "mono-cœur" (moderne).Citation:
Envoyé par loufoque
-W
A.Alexandrescu ne s'intéresse qu'à marquer les objets et les fonctions histoire que seuls ceux de même contexte (thread-safe ou pas) puisse s'appeler (tout en supportant les conversions implicites qui vont bien). Il étend ce que le compilo peut faire pour nous en termes de const-safety à la thread-safety.Citation:
Envoyé par wiztricks
Ah d'accord.
En farfouillant, j'ai trouvé ceci du même auteur. Sous le titre "C++ and the Perils of Double-Checked Locking", il aborde le même sujet.
A la fin, ils font un historique en mentionnant les utilisations actuelles:
So when dealing with some memory locations (e.g. memory mapped ports or
memory referenced by ISRs), some optimizations must be suspended. volatile exists for specifying special treatment for such locations, specifically: (1) the content of a volatile variable is “unstable” (can change by means unknown to the compiler), (2) all writes to volatile data are “observable” so they must be executed religiously, and (3) all operations on volatile data are executed in the sequence in which they appear in the source code. The first two rules ensure proper reading and writing. The last one allows implementation of I/O protocols that mix input and output.
This is informally what C and C++’s volatile guarantees.
Java took volatile a step further by guaranteeing the properties above
across multiple threads. This was a very important step, but it wasn’t enough
to make volatile usable for thread synchronization: the relative ordering of
volatile and non-volatile operations remained unspecified. This ommission
forces many variables to be volatile to ensure proper ordering.
Java 1.5’s volatile [10] has the more restrictive, but simpler, acquire/release
semantics : any read of a volatile is guaranteed to occur prior to any memory reference (volatile or not) in the statements that follow, and any write to a volatile is guaranteed to occur after all memory references in the statements preceding it. .NET defines volatile to incorporate multithreaded semantics as well, which are very similar to the currently proposed Java semantics. We know of no similar work being done on C’s or C++’s volatile.
=> La JVM et la CLR semblent avoir étendu la notion de "volatile" pour effectuer un "memory barrier".... Mais bon quelle part, le code s'exécute sur une machine virtuelle par sur les machines réelles.
-W
C'est un peu le même principe que ce que Scott Meyers propose et étend dans http://www.artima.com/cppsource/codefeatures.html si j'ai bien suivi.Citation:
Envoyé par Luc Hermitte
Si. Dans une première partie il donne à volatile des effets qu'il n'a pas. Mais dans la deuxième, il s'en sert uniquement pour jouer avec ses propriétés sur le système de type (LockingPtr n'est là que pour assurer que quand on utilise les membres non volatile, on a bien acquis un mutex).Citation:
Envoyé par wiztricks
Tu as des exemples de problèmes (soit je ne t'ai pas compris, soit il me semble qu'il n'y en a pas).Citation:
Envoyé par wiztricks
Si j'ai bien compris, en Java, volatile agit comme une barrière d'optimisation mais pas comme une barrière mémoire. Non ?Citation:
Envoyé par wiztricks
L'article http://www.artima.com/cppsource/codefeatures.html m'a éclairé sur ce que vous entendiez par là. Merci pour le pointeur.Citation:
Envoyé par Jean-Marc.Bourguet
Dans un système, le CPU n'est pas le seul gadget pouvant avoir un accès direct à la mémoire...Citation:
Tu as des exemples de problèmes (soit je ne t'ai pas compris, soit il me semble qu'il n'y en a pas).Citation:
Envoyé par wiztricks Voir le message
C'est bien pire: "ca ne fait pas de "memory barrier" donc çà peut faire n'importe quoi même sur un "mono-cœur" (moderne).
-W
- W
Je ne comprend pas trop ce que vous entendez par "barrière d'optimisation".Citation:
Envoyé par Montag
Voir modèle mémoire de la JVM et les articles données en référence. Ils sont assez instructifs.
-W
Ma comprehension (d'apres entre autres des messages de John Mashey sur comp.arch relatant le contexte de l'introduction de volatile dans le langage C) c'est que volatile doit alors suffire, mais c'est a charge de l'utilisateur de ne le faire que sur des zones non cachees (et donc il faudrait que volatile introduise des barrieres sur Sparc puisqu'il n'y a pas moyen de regler le MMU pour qu'elles ne soient pas necessaires).Citation:
Envoyé par wiztricks
Mais ce qui est sur c'est qu'au mieux la semantique desiree de volatile est sous-specifiee, au pire elle n'est pas specifiable dans le modele d'execution utilise par les normes C et C++ pour specifier leur semantique.
Pour moi une barrière d'optimisation est une "barrière" qui empêche le compilateur de réordonner certains accès mémoire alors q'une barrière mémoire ("mémoire fence") agit au niveau du hardware.Citation:
Envoyé par wiztricks
Ceci étant dit, ce que j'ai dit dans mon post précédent est faux puisque apparemment (d'après les liens que tu as donnés) en Java volatile agit à la fois comme une barrière d'optimisation et comme une barrière mémoire.
Disons que le contexte dans lequel "volatile" a été initialement conçu pour dire au compilateur d'éviter certaines optimisations.Citation:
Envoyé par Jean-Marc.Bourguet
Bien que suffisant dans beaucoup de cas, cela ne rend pas compte des spécificités des architectures matérielles. Soit on laisse le programmeur s'en débrouiller, soit on fait comme Java, ie le langage propose un modèle mémoire indépendant de l'architecture.
Il y a eu pas mal de réflexions sur le sujet dans le cadre de C++0x. Mais j'ignore si cela a abouti à un "bon" compromis.Citation:
Mais ce qui est sur c'est qu'au mieux la semantique desiree de volatile est sous-specifiee, au pire elle n'est pas specifiable dans le modele d'execution utilise par les normes C et C++ pour specifier leur sémantique.
-W