signification de mutable et volatile

kanze

24/12/2004 à 09:38

Gabriel Dos Reis wrote:

writes:

[...]

| Mais c'est effectivement important à noter qu'au contraire de
| mutable, il fait bien partie du système de types.

Ah, « mutable » ne fait plus partie du système de type. Depuis
quand ?

Depuis qu'il existe. Lis la norme -- c'est un « storage class
specifier », comme auto ou register.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze

24/12/2004 à 09:44

drkm wrote:

"Christophe Lephay" writes:

Je ne parle pas de ce qui est écrit dans la norme mais de la
réponse

de drkm qu'il oppose à la phrase de James.

Je ne sais pas ce que tu veux d'autre que ce que dit la norme (dont
un extrait constituait d'ailleurs ma seule réponse à James). James
disait :

Mais ce qui constitue un accès dans cette contexte
est

défini par l'implémentation.

Ce à quoi j'ai répondu :

Même pas, « because the value of the object might be changed
by

means undetectable by an implementation ».

Quelque chose qui échappe à une implémentation n'est pas défini
par

elle. Si ?

Mais quel rapport. Tous les « accès » ne proviennent pas de
l'implémentation, et surtout, on considère ici la possibilité que la
valeur peut changer sans un accès.

En fait, ça correspond à une réalité avec laquelle tout le monde
qui a
travaillé sur des processeurs embarqué est confrontée. On peut ne
pas
être d'accord avec le langage de la norme -- je crois que les auteurs
n'en étaient pas particulièrement satisfaits non plus. Mais dans ce
cas-là, propose quelque chose de mieux.

Parce que si on veut se servir de C/C++ dans les systèmes embarqués
ou
pour les pilotes de périphérique, il faut bien quelque chose.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jean-Marc Bourguet

24/12/2004 à 11:10

"Alain Naigeon" writes:

"Gabriel Dos Reis" a écrit dans le message
news:

qu'appelles-tu « optimiser » ?

Comme d'habitude, tu connais la réponse à ta question.
Mais puisque ça m'intéresse de voir où tu veux en venir,
voici juste l'exemple de deux affectations :
x = a ;
y = a ;
(mettons que ce soient des entiers)

J'ai déjà vu du code généré qui ressemblait à ceci :
1 chercher la valeur de a en mémoire et la charger dans un registre
2 copie du registre vers l'emplacement mémoire de x
3 chercher valeur de a et la charger en registre (le même)
4 copie du registre vers emplecament mémoire de y

On peut être tenté d'omettre l'étape 3 ;-)
J'appelle ça une optimisation.

L'effet pratique des caches est d'omettre l'étape 3 même si
elle est présente dans le code. Si tu appelles aussi ne pas
émettre des instructions de synchronisation de cache des
optimisations, tu es vraissemblablement un peu seul...

Maintenant, s'agissant de 4 instructions machine, ce code
est interruptible, et par conséquent dans un contexte multi
thread rien ne garantit que les deux façons de faire seront
équivalentes puisque a peut avoir été modifié by means
undetectable by the present implementation.

Je dis aussi que volatile interdit l'omission mentionnée
ci-dessus.

Le problème à nouveau ce n'est pas les changements de
contextes sur les systèmes uni-processeurs -- dans ce cas-là
volatile fait plus ou moins ce qui est désiré. Le problème
est avec du multi-thread sur des multi-processeurs. Pour
utiliser la mémoire comme moyen de communication entre
threads (ce qui n'est pas absolument nécessaire, voir les
systèmes à passage de messages qui ont généralement un
meilleur comportement quand le nombre de processeurs
augmentent) il faut s'assurer que les caches sont bien
invalidés et rechargés comme il faut. Ce qui n'est pas le
cas habituellement avec volatile. Et même si ce l'était, il
faudrait marquer comme volatile toutes les variables
partagées parce que volatile n'implique rien sur celles-ci
et qu'un cache cohérent pour une donnée peut ne pas l'être
pour une autre.

Un problème avec les caches, est que certains systèmes
offrent des garanties plus fortes que d'autres en l'absence
d'instruction de synchronisation. En particulier dans les
relations d'ordre de visibilité. Donc qqch peut fonctionner
sur un système et pas sur l'autre.

Volatile en dehors des rares cas prévus par la norme
(longjmp et signaux) n'a vraissemblablement d'utilité qu'à
très bas niveau, pour des accès à des zones mémoires non
cachées (IO principalement).

Note que dans les problèmes de synchronisation (ou faire un
accès avant un autre a de l'importance), le réordonnement
peut être fait aussi bien par le compilateur que par le
processeur (les processeurs actuels exécutent les
instructions dans un ordre potentiellement différent de
l'ordre linéraire, et cet effet peut être visible) ou par
les caches. Volatile influence le compilateur, mais à ma
connaissance pas au point de le faire empécher les
réordonnements par les autres couches.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

"Alain Naigeon" <anaigeon@free.fr> writes:

"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
news: m33bxwrcl6.fsf@uniton.integrable-solutions.net...

qu'appelles-tu « optimiser » ?

Comme d'habitude, tu connais la réponse à ta question.
Mais puisque ça m'intéresse de voir où tu veux en venir,
voici juste l'exemple de deux affectations :
x = a ;
y = a ;
(mettons que ce soient des entiers)

J'ai déjà vu du code généré qui ressemblait à ceci :
1 chercher la valeur de a en mémoire et la charger dans un registre
2 copie du registre vers l'emplacement mémoire de x
3 chercher valeur de a et la charger en registre (le même)
4 copie du registre vers emplecament mémoire de y

On peut être tenté d'omettre l'étape 3 ;-)
J'appelle ça une optimisation.

L'effet pratique des caches est d'omettre l'étape 3 même si
elle est présente dans le code. Si tu appelles aussi ne pas
émettre des instructions de synchronisation de cache des
optimisations, tu es vraissemblablement un peu seul...

Maintenant, s'agissant de 4 instructions machine, ce code
est interruptible, et par conséquent dans un contexte multi
thread rien ne garantit que les deux façons de faire seront
équivalentes puisque a peut avoir été modifié by means
undetectable by the present implementation.

Je dis aussi que volatile interdit l'omission mentionnée
ci-dessus.

Le problème à nouveau ce n'est pas les changements de
contextes sur les systèmes uni-processeurs -- dans ce cas-là
volatile fait plus ou moins ce qui est désiré. Le problème
est avec du multi-thread sur des multi-processeurs. Pour
utiliser la mémoire comme moyen de communication entre
threads (ce qui n'est pas absolument nécessaire, voir les
systèmes à passage de messages qui ont généralement un
meilleur comportement quand le nombre de processeurs
augmentent) il faut s'assurer que les caches sont bien
invalidés et rechargés comme il faut. Ce qui n'est pas le
cas habituellement avec volatile. Et même si ce l'était, il
faudrait marquer comme volatile toutes les variables
partagées parce que volatile n'implique rien sur celles-ci
et qu'un cache cohérent pour une donnée peut ne pas l'être
pour une autre.

Un problème avec les caches, est que certains systèmes
offrent des garanties plus fortes que d'autres en l'absence
d'instruction de synchronisation. En particulier dans les
relations d'ordre de visibilité. Donc qqch peut fonctionner
sur un système et pas sur l'autre.

Volatile en dehors des rares cas prévus par la norme
(longjmp et signaux) n'a vraissemblablement d'utilité qu'à
très bas niveau, pour des accès à des zones mémoires non
cachées (IO principalement).

Note que dans les problèmes de synchronisation (ou faire un
accès avant un autre a de l'importance), le réordonnement
peut être fait aussi bien par le compilateur que par le
processeur (les processeurs actuels exécutent les
instructions dans un ordre potentiellement différent de
l'ordre linéraire, et cet effet peut être visible) ou par
les caches. Volatile influence le compilateur, mais à ma
connaissance pas au point de le faire empécher les
réordonnements par les autres couches.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Vous avez filtré cet utilisateur ! Consultez son message

"Alain Naigeon" writes:

"Gabriel Dos Reis" a écrit dans le message
news:

qu'appelles-tu « optimiser » ?

Comme d'habitude, tu connais la réponse à ta question.
Mais puisque ça m'intéresse de voir où tu veux en venir,
voici juste l'exemple de deux affectations :
x = a ;
y = a ;
(mettons que ce soient des entiers)

J'ai déjà vu du code généré qui ressemblait à ceci :
1 chercher la valeur de a en mémoire et la charger dans un registre
2 copie du registre vers l'emplacement mémoire de x
3 chercher valeur de a et la charger en registre (le même)
4 copie du registre vers emplecament mémoire de y

On peut être tenté d'omettre l'étape 3 ;-)
J'appelle ça une optimisation.

L'effet pratique des caches est d'omettre l'étape 3 même si
elle est présente dans le code. Si tu appelles aussi ne pas
émettre des instructions de synchronisation de cache des
optimisations, tu es vraissemblablement un peu seul...

Maintenant, s'agissant de 4 instructions machine, ce code
est interruptible, et par conséquent dans un contexte multi
thread rien ne garantit que les deux façons de faire seront
équivalentes puisque a peut avoir été modifié by means
undetectable by the present implementation.

Je dis aussi que volatile interdit l'omission mentionnée
ci-dessus.

Le problème à nouveau ce n'est pas les changements de
contextes sur les systèmes uni-processeurs -- dans ce cas-là
volatile fait plus ou moins ce qui est désiré. Le problème
est avec du multi-thread sur des multi-processeurs. Pour
utiliser la mémoire comme moyen de communication entre
threads (ce qui n'est pas absolument nécessaire, voir les
systèmes à passage de messages qui ont généralement un
meilleur comportement quand le nombre de processeurs
augmentent) il faut s'assurer que les caches sont bien
invalidés et rechargés comme il faut. Ce qui n'est pas le
cas habituellement avec volatile. Et même si ce l'était, il
faudrait marquer comme volatile toutes les variables
partagées parce que volatile n'implique rien sur celles-ci
et qu'un cache cohérent pour une donnée peut ne pas l'être
pour une autre.

Un problème avec les caches, est que certains systèmes
offrent des garanties plus fortes que d'autres en l'absence
d'instruction de synchronisation. En particulier dans les
relations d'ordre de visibilité. Donc qqch peut fonctionner
sur un système et pas sur l'autre.

Volatile en dehors des rares cas prévus par la norme
(longjmp et signaux) n'a vraissemblablement d'utilité qu'à
très bas niveau, pour des accès à des zones mémoires non
cachées (IO principalement).

Note que dans les problèmes de synchronisation (ou faire un
accès avant un autre a de l'importance), le réordonnement
peut être fait aussi bien par le compilateur que par le
processeur (les processeurs actuels exécutent les
instructions dans un ordre potentiellement différent de
l'ordre linéraire, et cet effet peut être visible) ou par
les caches. Volatile influence le compilateur, mais à ma
connaissance pas au point de le faire empécher les
réordonnements par les autres couches.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

drkm

24/12/2004 à 11:55

writes:

drkm wrote:

Mais ce qui constitue un accès dans cette contexte
est défini par l'implémentation.

Ce à quoi j'ai répondu :

Même pas, « because the value of the object might be changed
by means undetectable by an implementation ».

Quelque chose qui échappe à une implémentation n'est pas défini
par elle. Si ?

Mais quel rapport. Tous les « accès » ne proviennent pas de
l'implémentation, et surtout, on considère ici la possibilité que la
valeur peut changer sans un accès.

Mais comment une implémentation peut-elle « définir » ce qu'est un
accès lorsque tout peut arriver par ailleurs ?

--drkm

drkm

24/12/2004 à 12:06

writes:

drkm wrote:

writes:

Mais ce qui constitue un accès dans cette contexte
est défini par l'implémentation.

Même pas, « because the value of the object might be changed by
means undetectable by an implementation ».

Ça, c'est un autre aspect. Ici, il n'est question que des « accès »
par l'implémentation.

Est-il possible pour l'implémentation de « définir » les accès à des
« choses » sur lesquelles elle ne peut avoir aucune garantie ?

--drkm

Gabriel Dos Reis

24/12/2004 à 19:07

drkm writes:

| writes:
|
| > drkm wrote:
|
| >> >>> Mais ce qui constitue un accès dans cette contexte
| >> >>> est défini par l'implémentation.
|
| >> Ce à quoi j'ai répondu :
|
| >> >> Même pas, « because the value of the object might be changed
| >> >> by means undetectable by an implementation ».
|
| >> Quelque chose qui échappe à une implémentation n'est pas défini
| >> par elle. Si ?
|
| > Mais quel rapport. Tous les « accès » ne proviennent pas de
| > l'implémentation, et surtout, on considère ici la possibilité que la
| > valeur peut changer sans un accès.
|
| Mais comment une implémentation peut-elle « définir » ce qu'est un
| accès lorsque tout peut arriver par ailleurs ?

Bonne chance :-)

-- Gaby

Gabriel Dos Reis

24/12/2004 à 19:11

"Alain Naigeon" writes:

| "Gabriel Dos Reis" a écrit dans le message
| news:
|
| > qu'appelles-tu « optimiser » ?
|
|
| Comme d'habitude, tu connais la réponse à ta question.

Bah non, puisque c'est toi qui utilises un terme que je ne comprends pas.

| Mais puisque ça m'intéresse de voir où tu veux en venir,
| voici juste l'exemple de deux affectations :
| x = a ;
| y = a ;
| (mettons que ce soient des entiers)
|
| J'ai déjà vu du code généré qui ressemblait à ceci :
| 1 chercher la valeur de a en mémoire et la charger dans un registre
| 2 copie du registre vers l'emplacement mémoire de x
| 3 chercher valeur de a et la charger en registre (le même)
| 4 copie du registre vers emplecament mémoire de y
|
| On peut être tenté d'omettre l'étape 3 ;-)
| J'appelle ça une optimisation.

mais, je ne sais pas ce que c'est qu'un registre. Et surtout comment
je vérifie que c'est quelque chose que fait le compilateur ?

|
| Maintenant, s'agissant de 4 instructions machine, ce code
| est interruptible,

Comment et où ?

| et par conséquent dans un contexte multi
| thread

la norme ne définit pas ce qu'est une contxte multi-thread, donc
j'aimerais que tu éclaircisses ton propos. Merci d'avance.

| rien ne garantit que les deux façons de faire seront
| équivalentes puisque a peut avoir été modifié by means
| undetectable by the present implementation.
|
| Je dis aussi que volatile interdit l'omission mentionnée
| ci-dessus.

?

-- Gaby

Alain Naigeon

24/12/2004 à 19:52

"Gabriel Dos Reis" a écrit dans le message
news:

"Alain Naigeon" writes:

| "Gabriel Dos Reis" a écrit dans le
message

| news:
|
| > qu'appelles-tu « optimiser » ?
|
|
| Comme d'habitude, tu connais la réponse à ta question.

Bah non, puisque c'est toi qui utilises un terme que je ne comprends pas.

Alors il y a plein de livres dont le sens a dû t'échapper.

| Mais puisque ça m'intéresse de voir où tu veux en venir,
| voici juste l'exemple de deux affectations :
| x = a ;
| y = a ;
| (mettons que ce soient des entiers)
|
| J'ai déjà vu du code généré qui ressemblait à ceci :
| 1 chercher la valeur de a en mémoire et la charger dans un registre
| 2 copie du registre vers l'emplacement mémoire de x
| 3 chercher valeur de a et la charger en registre (le même)
| 4 copie du registre vers emplecament mémoire de y
|
| On peut être tenté d'omettre l'étape 3 ;-)
| J'appelle ça une optimisation.

mais, je ne sais pas ce que c'est qu'un registre.

Ah !!! Tu n'as jamais fait d'assembleur non plus.

Et surtout comment
je vérifie que c'est quelque chose que fait le compilateur ?

Je croyais tu écrivais des parties de compilateurs.

|
| Maintenant, s'agissant de 4 instructions machine, ce code
| est interruptible,

Comment et où ?

Bah, tu sais, j'ai programmé des routines d'interruption,
alors arrête de botter en touche sans apporter un seul
élément positif, ce n'est pas une façon de débattre.

[...]

?

<mode Gaby>
!
</mode Gaby>

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France

Gabriel Dos Reis

25/12/2004 à 03:10

"Alain Naigeon" writes:

[...]

| > Et surtout comment
| > je vérifie que c'est quelque chose que fait le compilateur ?
|
| Je croyais tu écrivais des parties de compilateurs.

Mais cela n'explique pas ce que tu as écrit. Et tsurtout cela ne
m;explique pas comment *tu* envisages qu'on vérifie ce que le
compilateur pond.

| > |
| > | Maintenant, s'agissant de 4 instructions machine, ce code
| > | est interruptible,
| >
| > Comment et où ?
|
| Bah, tu sais, j'ai programmé des routines d'interruption,
| alors arrête de botter en touche sans apporter un seul
| élément positif,

Tu fais des affirmations ; on te demande plus d'explications et des
justifications et tu appelles cela botter en touche. Ahem.

| ce n'est pas une façon de débattre.

tu t'es vu quand t'as bu ?

-- Gaby

Alain Naigeon

25/12/2004 à 16:33

"Gabriel Dos Reis" a écrit dans le message
news:

"Alain Naigeon" writes:

[...]

| > Et surtout comment
| > je vérifie que c'est quelque chose que fait le compilateur ?
|
| Je croyais tu écrivais des parties de compilateurs.

Mais cela n'explique pas ce que tu as écrit. Et tsurtout cela ne
m;explique pas comment *tu* envisages qu'on vérifie ce que le
compilateur pond.

Le "on" est significatif d'une confusion : moi, utilisateur du langage,
je n'ai rien à vérifier ; j'attends simplement qu'on tienne la promesse
donnée par le mot "volatile", certainement pas choisi par hasard,
c'est à dire : générer quelque chose d'assez proche de ce que j'ai
écrit pour qu'en aucune circonstance le résultat ne soit différent
d'une traduction totalement fidèle. En l'occurrence, c'est à ceux
ayant inventé volatile de s'assurer qu'il est implémentable. Si tu
penses qu'il ne l'est pas, il faut envoyer un message fort aux
utilisateurs du langage pour demander officiellement qu'il en soit
retiré.

| > |
| > | Maintenant, s'agissant de 4 instructions machine, ce code
| > | est interruptible,
| >
| > Comment et où ?
|
| Bah, tu sais, j'ai programmé des routines d'interruption,
| alors arrête de botter en touche sans apporter un seul
| élément positif,

Tu fais des affirmations ; on te demande plus d'explications et des
justifications et tu appelles cela botter en touche. Ahem.

Oui, c'est ça :
1 load
2 store
3 load
4 store

Si tu supprimes le 3, tu peux avoir une interruption
après le 2, qui peut changer la valeur en mémoire,
ce qui rend le 4 obsolete puisque l'interruption a
laissé le registre inchangé. Que veux-tu de plus ?

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France

signification de mutable et volatile

10 réponses

Veuillez sélectionner un problème