Discussion :

[oodini]

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.

[Jean-Marc.Bourguet]

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.

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.

[JolyLoic]

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.

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 ?

[Jean-Marc.Bourguet]

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 ?

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.

[wiztricks]

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

[Luc Hermitte]

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.

[loufoque]

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!".

Sauf que comme ça fait pas de memory barriers ça marche qu'en mono-cœur...

[wiztricks]

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.

J'ai relu l'article mentionné mais il ne semble pas aller aussi loin que vous le proposez.
- W

[wiztricks]

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

[oodini]

Et si on utilise les mutex de boost, je suppose donc qu'on peut également se passer de volatile ?

[Jean-Marc.Bourguet]

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.

[Luc Hermitte]

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é.