hI,
 
le mot clef volatile en c++ a t-il encore un intérêt ?
 
Merci.

en embarque quand tu sniffes des registre materiels. sinon non et surtout pas pour ce que tu espere en faire en multithread

Et dans les routines d'interruption.

 
Je serais pas contre une petite réargumentation à ce sujet. Mon Stroustrup et mon K&R n'ont pas vraiment éclairci le sujet.
Dans le cas d'un multi procs, ca peut sembler utile si ca vient effectivement forcer les relectures depuis la mémoire, non ?

 
Le compilateur ne peut pas déterminer qu'une variable est modifiée quand c'est un registre hardware ou quand elle est modifiée depuis un autre thread. La variable volatile indique juste au compilateur de ne pas tenter d'optimiser une variable.  
C'est assez bien expliqué ici: http://en.wikipedia.org/wiki/Volatile_variable
 
Je pense que par "sinon non et surtout pas pour ce que tu espere en faire en multithread", il voulait dire que déclarer une variable volatile ne remplace pas une section critique.
 
Et moi aussi je veux l'explication plus correcte/complète de Joel F

Euh, tu n'as pas du bien lire le Stroustrup alors, car il indique bien que la directive a pour effet d’empêcher certaines optimisations. Elle ne force rien du tout.
A+,
 

 
 
Je t'avoue que je ne l'ai pas retrouvé dans le stroustrup et je viens d'y jeter à nouveau un oeil, je vois mal dans quel chapitre ca tombe. Cela dit, le K&R est aussi clair là-dessus : ca empêche certaines optimisations comme tu le dis, mais ... L'optimisation qu'on veut en général voir éviter, c'est la suppression de la relecture mémoire d'une variable qui sert dans une boucle mais qui n'y est pas modifiée. Retirer cette optimisation "force" donc à faire un accès à cette zone mémoire au sein de la boucle. C'est précisément le cas qui m'intéresse, d'où mon raccourci : "forcer les relectures". Maintenant que mon point est éclairci, la subtilité qui me chiffonne, c'est de savoir ce qui se passe au niveau du cache des processeurs dans ce genre de contexte. Il me semble que sur certaines architectures (power pc pour ne pas la citer), l'invalidation du cache d'autres processeurs quand l'un fait une modification mémoire est un peu bancale. L'idée, c'est donc de savoir si on peut avoir des garanties à ce niveau là.

ARM p 110 dans mon édition de 1990, section 7.1.6 Type Specifiers.

C'est sans doute dans d'autres bouquins de lui aussi, mais faudrait que je cherche sous quelle pile ils sont planqués.
A+,

 
volatile est sous-spécifié. Il force les accès de la machine virtuelle servant à définir la sémantique à correspondre aux accès de la machine physique, mais ce que signifie exactement accès n'est pas défini.
 
En pratique, volatile est implémenté pour servir les IO mappées en mémoire (et encore, gcc ne fait pas ce qu'il faut en théorie sur Sparc, je ne sais pas si ça marche en pratique, Sparc étant une spec, il est possible qu'aucune implémentation ne profite de la latitude qui fait que ce que gcc implémente n'est pas suffisant; mais c'est pas le propos ici).
 
Les cachent rendent ce qui est fait insuffisant pour du multi-thread.  La synchronisation des differents caches d'un processeur necessite parfois des instructions supplementaires pour avoir l'effet voulu (certains systemes ne synchronisent meme pas les acces a un emplacement memoire, la plupart ne garantissent pas grand chose comme relation quand ca concernent plusieurs emplacement).
 
Voir sur le site du comité les papiers sur le modele memoire (tu peut chercher Hans Boehm comme auteur, il n'a touche quasiment qu'a ca)

 
merci