Discussion :

[guillaume07]

Besoin d'une confirmation concernant l'exemple de ce lien :

http://cpp.developpez.com/faq/cpp/?p...IVERS_volatile

Le problème plus précisement qu'il n'est expliquer dans le lien, est -il le suivant :

Un autre thread (autre que celui qui éxécute le while(!drapeau) vient modifier la variale drapeau mais modifié en faite uniquement la valeur de celle ci en RAM alors que le thread utilisé pour éxécuter le while utilise une "copie" de cette variable stocké dans les registres du processeur, ainsi le thread qui éxécute le while continuera à boucler car pour lui le drapeau n'a pas été modifié .

c'est ça ou pas du tout ?

[3DArchi]

Je n'ai pas vraiment compris ta question mais :
1/ Le compilateur peut très bien décider de ne pas réévaluer une variable s'il détermine qu'elle ne peut changer dans entre ses deux utilisations
2/ volatile est là pour lui dire justement qu'un changement peut avoir lieu là même s'il ne le voit pas. volatile répond à un problème bas niveau qui est qu'on utilise en général le même emplacement mémoire pour enchaîner des commandes ou lire des données. Par exemple, deux lecture successives sur une flash peuvent donner un résultat différent indiquant qu'elle est en train de faire quelque chose et donc sa lecture est impossible. Ce qui en code peut se traduire par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
volatile TYPE_flash_word *ptr_flash = SOME_ADRESS;
TYPE_flash_word w1;
TYPE_flash_word w2;
w1 = *ptr_flash;
w2 = *ptr_flash;
if(w1!=w2)
{// flash au boulot
}
else
{// boulot terminé
}

Sans volatile, le compilateur aurait pu sauvagement optimiser et résumé ce code à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
volatile TYPE_flash_word *ptr_flash = SOME_ADRESS;
TYPE_flash_word w1;
w1 = *ptr_flash;
{// boulot terminé
}

Ce que la F.A.Q. indique c'est que volatile n'est pas fait pour garantir une protection contre le multithreading car une lecture ou une écriture peut ne pas être atomique, notion différente de volatile

[guillaume07]

finalement j'ai du mal à en déduire une règle à appliquer pour savoir dans quel cas je mets volatile et dans quel cas c'est superflu

EDIT: par rapport à mon poste je pensais juste que dans certains cas, une variable qui se retrouve stocké dans un registre processeur, peut voir sa version stocké en ram modifié par un thread par exemple, la version de cette variable stocké dans le registre processeur restant inchangé ce qui conduirait ainsi à une incohérence, mais je suis peut être totalement dans le faux

[ram-0000]

finalement j'ai du mal à en déduire une règle à appliquer pour savoir dans quel cas je mets volatile et dans quel cas c'est superflu

On met volatile quand une variable peut être modifiée alors que le compilateur ne peut pas le deviner. Cette modification est faite en dehors du contexte du programme.

Un autre exemple, une variable mémoire modifiée par une interruption (clavier par exemple). Le compilateur ne paut pas savoir quand l'utilisateur va appuyer sur le clavier et donc les accès à cette variable ne doivent pas être optimisés par le compilateur.

Comme indiqué avant, volatile est surtout utilisé quand on fait de la programmation hardware de bas niveau.

[guillaume07]

On met volatile quand une variable peut être modifiée alors que le compilateur ne peut pas le deviner. Cette modification est faite en dehors du contexte du programme.

Un autre exemple, une variable mémoire modifiée par une interruption (clavier par exemple). Le compilateur ne paut pas savoir quand l'utilisateur va appuyer sur le clavier et donc les accès à cette variable ne doivent pas être optimisés par le compilateur.

Comme indiqué avant, volatile est surtout utilisé quand on fait de la programmation hardware de bas niveau.

ok ok mais techniquement quel est le problème qui va se poser? qu'est ce qui change quand les accès à cette variable sont optimisés par le compilateur ? quel sénario peut se passer, qui amenerer une incohérence ?

EDIT:il s'agit bien d'un problème d'une variable se trouvant à la fois dans un registre processeur et dans la RAM ?

[Astraya]

Bonjour,

Le mot clé volatile est surtout utilisé dans un contexte de multiprogrammation. Il servira à dire au compilateur de ne pas procéder à des optimisations trop violente sur tel ou tel variable.
Par exemple, une boucle while avec un bool qui n'est pas modifier autre par que dans un autre thread. Le compilateur pourra l'optimiser et par malheur détruite la logique du programme.

[ram-0000]

ok ok mais techniquement quel est le problème qui va se poser? qu'est ce qui change quand les accès à cette variable sont optimisés par le compilateur ? quel sénario peut se passer, qui amenerer une incohérence ?

imaginons le programme suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
bool keyboard = false;
if(keyboard == true)
{
   traiter_touche();
}

Si le compilateur se rend compte que la variable keyboard n'est jamais modifiée et vaut toujours false, il peut être tenté d'optimiser le code en supprimant l'appel à la fonction "traiter_touche()" car il se rend compte que le test "if(keyboard == true)" ne sera jamais vrai. Si on met "volatile bool keyboard", on indique au compilateur qu'il n'a pas le droit d'optimiser en déduisant (mal) que la valeur ne changera jamais.

EDIT:il s'agit bien d'un problème d'une variable se trouvant à la fois dans un registre processeur et dans la RAM ?

Non

[guillaume07]

imaginons le programme suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
bool keyboard = false;
if(keyboard == true)
{
   traiter_touche();
}

Si le compilateur se rend compte que la variable keyboard n'est jamais modifiée et vaut toujours false, il peut être tenté d'optimiser le code en supprimant l'appel à la fonction "traiter_touche()" car il se rend compte que le test "if(keyboard == true)" ne sera jamais vrai. Si on met "volatile bool keyboard", on indique au compilateur qu'il n'a pas le droit d'optimiser en déduisant (mal) que la valeur ne changera jamais.


Non

bon ok merci bien. ceci dit pas sûr concernant ton "Non" , j'aimerais bien d'autre source qui confirme/infirme ça me sembler très logique mais bon..

la question que je me pose finalement c'est comment niveau assembleur les threads sont ils gérés , changement de contexte, les registres du proc sauvegarder, rechargés quand où etc

[gl]

bon ok merci bien. ceci dit pas sûr concernant ton "Non" , j'aimerais bien d'autre source qui confirme/infirme ça me sembler très logique mais bon

Pour être précis, un des effets de volatile est d'empêcher le passage en registre d'une variable.
Mais c'est loin d'être le seul effet (entre autre il y a la non-suppression de code vu comme mort, ne pas calculer à la compilation des expressions qui sembleraient constante).

D'une manière générale, le compilateur n'effectue plus les optimisations concernant une valeur à priori connue.

[guillaume07]

ça empêche le passage en registre ou ça force la relecture de la variable en RAM ?

[3DArchi]

Pour être précis, un des effets de volatile est d'empêcher le passage en registre d'une variable.

Faudra que je vérifie car cela me semble être une contrainte forte.

ça empêche le passage en registre ou ça force la relecture de la variable en RAM ?

Pour moi, cela force à faire tous les accès à cette variable même si elle a l'air de ne pas avoir changé d'une fois sur l'autre. En RAM cela ne veut rien dire, car cela peut être du mapping d'adresse d'un composant HW (port LCD, UART, flash, etc.)

[guillaume07]

oui disons en mémoire d'une plus générale effectivement

[gl]

Faudra que je vérifie car cela me semble être une contrainte forte.

Je viens de m'apercevoir en me relisant suite à ta remarque que ma phrase est très très mal formulée. Lorsque je parle de passage, il ne s'agit aucunement du passage de paramètre (mais du changement de localisation).

J'aurais plutôt du écrire :

Pour être précis, un des effets possibles de volatile est d'empêcher l'optimisation qui consiste à stocker la valeur d'une variable dans un registre plutôt que de lire à chaque accès l'emplacement mémoire correspondant.

En outre ce n'est, à ma connaissance, qu'un choix possible pas une obligation. Tant que le mécanisme utilisé permette bien de lire la valeur en mémoire à chaque fois.

[Médinoc]

Il y a une différence entre ce que la norme garantit de volatile (utilisation avec signal() et type sig_atomic_t) et ce qu'une implémentation donnée garantit:

Par exemple, Microsoft Windows 32 bits garantit que certaines opérations soient atomiques, et que le scénario "classique" d'utilisation inter-thread de volatile marche:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <stdio.h>
#include <process.h>
 
volatile int g_var;
 
unsigned int __stdcall threadproc(void*)
{
	while(g_var==0) {}
	puts("Salut!");
	g_var = 0;
}
 
int main(void)
{
	unsigned int id;
	g_var = 0;
 
	_beginthreadex(NULL, 0, threadproc, NULL, 0, &id);
	g_var = 1;
	while(g_var==1) {}
	puts("Fin.");
	return 0;
}

[guillaume07]

je suis déçus je m'attendais à ce qu'il y est un changement de comportement en fonction de la présence ou non du mot clef volatile

[koala01]

Salut,

je suis déçus je m'attendais à ce qu'il y est un changement de comportement en fonction de la présence ou non du mot clef volatile

Le fait est qu'il y a changement de comportement, mais qu'il n'est pas directement visible:

• Au niveau du compilateur, d'abord : cela lui interdit un certain nombre d'optimisations qu'il serait susceptible d'effectuer
• Au niveau de l'exécution, ensuite : cela t'assure, quelle que soit la manière dont c'est mis en oeuvre, quela valeur de la variable déclarée volatile sera réévaluée de manière systématique à chaque fois que l'on tentera d'y accéder, et cela, même si, a priori, rien ne laisse présager que la valeur aura changé.

Avoue que c'est déjà pas si mal pour quelque chose qui ne provoque "aucun changement de comportement"

[guillaume07]

koala, c'est ton deuxième point qui m’intéresse particulièrement:
quand tu dis "réévaluer" dans quel cas ne pourrait-elle pas l'être, si elle se trouve soit en cache soit dans un registre ? j'avoue que mes connaissances bas niveaux me font défaut ...

[gl]

quand tu dis "réévaluer" dans quel cas ne pourrait-elle pas l'être, si elle se trouve soit en cache soit dans un registre ? j'avoue que mes connaissances bas niveaux me font défaut ...

cf. le message de ram-0000 avec l'exemple sur le flag keyboard.

[guillaume07]

par rapport à son exemple :

"Si le compilateur se rend compte que la variable keyboard n'est jamais modifiée et vaut toujours false"

L'interruption clavier viendra bien exécuté du code de l'appli qui viendra à son tour modifier la variable keyboard, dans ce cas comment est-ce que le compilateur peut ne pas s'en rendre compte à la compilation (et que cela nécéssite donc l'emploi du mot clef volatile )?

[ram-0000]

L'interruption clavier viendra bien exécuté du code de l'appli qui viendra à son tour modifier la variable keyboard, dans ce cas comment est-ce que le compilateur peut ne pas s'en rendre compte à la compilation (et que cela nécéssite donc l'emploi du mot clef volatile )?

Et si le code de l'interruption n'est pas dans le code du programme ?

Par exemple, le programme mappe dans son espace mémoire un octet de mémoire physique qui est le moyen d'échange entre le clavier et le système. Si lors du mapping, on indique pas le mot clé volatile, cela risque de ne pas marcher. Le compilateur risque de s'autoriser des optimisations qui feront que cela ne fonctionnera pas.
Cet exemple n'est pas que théorique car cela fonctionnait comme cela il y a quelques années sur les PC (cela doit encore marcher comme cela mais c'est un peu plus complexe maintenant)