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.

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

[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]

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

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

[Luc Hermitte]

J'ai relu l'article mentionné mais il ne semble pas aller aussi loin que vous le proposez.
- 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.

[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

[JolyLoic]

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.

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.

[Jean-Marc.Bourguet]

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

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

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

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

[Montag]

=> 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

Si j'ai bien compris, en Java, volatile agit comme une barrière d'optimisation mais pas comme une barrière mémoire. Non ?

[wiztricks]

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

L'article http://www.artima.com/cppsource/codefeatures.html m'a éclairé sur ce que vous entendiez par là. Merci pour le pointeur.

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

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

Dans un système, le CPU n'est pas le seul gadget pouvant avoir un accès direct à la mémoire...
- W

[wiztricks]

Envoyé par wiztricks Voir le message
=> 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

Si j'ai bien compris, en Java, volatile agit comme une barrière d'optimisation mais pas comme une barrière mémoire. Non ?

Je ne comprend pas trop ce que vous entendez par "barrière d'optimisation".
Voir modèle mémoire de la JVM et les articles données en référence. Ils sont assez instructifs.
-W