| "drkm" a écrit dans le message de news: | | > 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 ». | | Ce n'est pas incompatible, si ?
Comment ?
| On peut définir ce qu'est un accès sans pour autant forcément le rendre | détectable, non ?
donc l'implémentation va définir ce que c'est qu'un accès à un objet volatile en termes de « means undetectable by an implementation » ? Et tu voudrais utiliser « volatile » ? Huh.
| "drkm" <usenet.fclcxx@fgeorges.org> a écrit dans le message de news:
| wkr7lg3n8u.fsf@fgeorges.org...
| > kanze@gabi-soft.fr 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 ».
|
| Ce n'est pas incompatible, si ?
Comment ?
| On peut définir ce qu'est un accès sans pour autant forcément le rendre
| détectable, non ?
donc l'implémentation va définir ce que c'est qu'un accès à un objet
volatile en termes de « means undetectable by an implementation » ?
Et tu voudrais utiliser « volatile » ? Huh.
| "drkm" a écrit dans le message de news: | | > 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 ». | | Ce n'est pas incompatible, si ?
Comment ?
| On peut définir ce qu'est un accès sans pour autant forcément le rendre | détectable, non ?
donc l'implémentation va définir ce que c'est qu'un accès à un objet volatile en termes de « means undetectable by an implementation » ? Et tu voudrais utiliser « volatile » ? Huh.
-- Gaby
Christophe Lephay
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes: | On peut définir ce qu'est un accès sans pour autant forcément le rendre | détectable, non ?
donc l'implémentation va définir ce que c'est qu'un accès à un objet volatile en termes de « means undetectable by an implementation » ? Et tu voudrais utiliser « volatile » ? Huh.
Je sais pas, c'est pas un comme un alias de pointeur. Le fait de définir la notion d'alias n'implique pas forcément qu'on puisse les détecter, il me semble.
Pour revenir au volatile, il se peut que la machine cible définisse des causes supplémentaires qui feraient qu'un tel accès serait indétectable, selon qu'il y a des interruptions sur le système ou non, du multitache concurrent (multiprocesseur, hyperthreading), ou encore de la mémoire partagée. Ce sont autant de causes possibles d'accès indétectables (j'en oublie certainement), et toutes ne sont pas nécessairement applicables à tous les systèmes et, du coup, à toutes les implémentations.
Il y a surement quelque chose qui m'échape ^^
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
news: m3oegkrff8.fsf@uniton.integrable-solutions.net...
"Christophe Lephay" <christophe-lephay@wanadoo.fr> writes:
| On peut définir ce qu'est un accès sans pour autant forcément le rendre
| détectable, non ?
donc l'implémentation va définir ce que c'est qu'un accès à un objet
volatile en termes de « means undetectable by an implementation » ?
Et tu voudrais utiliser « volatile » ? Huh.
Je sais pas, c'est pas un comme un alias de pointeur. Le fait de définir la
notion d'alias n'implique pas forcément qu'on puisse les détecter, il me
semble.
Pour revenir au volatile, il se peut que la machine cible définisse des
causes supplémentaires qui feraient qu'un tel accès serait indétectable,
selon qu'il y a des interruptions sur le système ou non, du multitache
concurrent (multiprocesseur, hyperthreading), ou encore de la mémoire
partagée. Ce sont autant de causes possibles d'accès indétectables (j'en
oublie certainement), et toutes ne sont pas nécessairement applicables à
tous les systèmes et, du coup, à toutes les implémentations.
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes: | On peut définir ce qu'est un accès sans pour autant forcément le rendre | détectable, non ?
donc l'implémentation va définir ce que c'est qu'un accès à un objet volatile en termes de « means undetectable by an implementation » ? Et tu voudrais utiliser « volatile » ? Huh.
Je sais pas, c'est pas un comme un alias de pointeur. Le fait de définir la notion d'alias n'implique pas forcément qu'on puisse les détecter, il me semble.
Pour revenir au volatile, il se peut que la machine cible définisse des causes supplémentaires qui feraient qu'un tel accès serait indétectable, selon qu'il y a des interruptions sur le système ou non, du multitache concurrent (multiprocesseur, hyperthreading), ou encore de la mémoire partagée. Ce sont autant de causes possibles d'accès indétectables (j'en oublie certainement), et toutes ne sont pas nécessairement applicables à tous les systèmes et, du coup, à toutes les implémentations.
Il y a surement quelque chose qui m'échape ^^
Gabriel Dos Reis
"Christophe Lephay" writes:
| "Gabriel Dos Reis" a écrit dans le message de | news: | > "Christophe Lephay" writes: | > | On peut définir ce qu'est un accès sans pour autant forcément le rendre | > | détectable, non ? | > | > donc l'implémentation va définir ce que c'est qu'un accès à un objet | > volatile en termes de « means undetectable by an implementation » ? | > Et tu voudrais utiliser « volatile » ? Huh. | | Je sais pas, c'est pas un comme un alias de pointeur.
Aucun rapport.
| Le fait de définir la | notion d'alias n'implique pas forcément qu'on puisse les détecter, il me | semble.
Ah bon ?
| Pour revenir au volatile, il se peut que la machine cible définisse des | causes supplémentaires qui feraient qu'un tel accès serait indétectable,
le compilateur connaît la machyine cible. Donc, si elle définit quelque chose, cela ne lui est pas inconnu.
| selon qu'il y a des interruptions sur le système ou non, du multitache | concurrent (multiprocesseur, hyperthreading), ou encore de la mémoire | partagée. Ce sont autant de causes possibles d'accès indétectables (j'en | oublie certainement), et toutes ne sont pas nécessairement applicables à | tous les systèmes et, du coup, à toutes les implémentations.
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
| news: m3oegkrff8.fsf@uniton.integrable-solutions.net...
| > "Christophe Lephay" <christophe-lephay@wanadoo.fr> writes:
| > | On peut définir ce qu'est un accès sans pour autant forcément le rendre
| > | détectable, non ?
| >
| > donc l'implémentation va définir ce que c'est qu'un accès à un objet
| > volatile en termes de « means undetectable by an implementation » ?
| > Et tu voudrais utiliser « volatile » ? Huh.
|
| Je sais pas, c'est pas un comme un alias de pointeur.
Aucun rapport.
| Le fait de définir la
| notion d'alias n'implique pas forcément qu'on puisse les détecter, il me
| semble.
Ah bon ?
| Pour revenir au volatile, il se peut que la machine cible définisse des
| causes supplémentaires qui feraient qu'un tel accès serait indétectable,
le compilateur connaît la machyine cible. Donc, si elle définit
quelque chose, cela ne lui est pas inconnu.
| selon qu'il y a des interruptions sur le système ou non, du multitache
| concurrent (multiprocesseur, hyperthreading), ou encore de la mémoire
| partagée. Ce sont autant de causes possibles d'accès indétectables (j'en
| oublie certainement), et toutes ne sont pas nécessairement applicables à
| tous les systèmes et, du coup, à toutes les implémentations.
| "Gabriel Dos Reis" a écrit dans le message de | news: | > "Christophe Lephay" writes: | > | On peut définir ce qu'est un accès sans pour autant forcément le rendre | > | détectable, non ? | > | > donc l'implémentation va définir ce que c'est qu'un accès à un objet | > volatile en termes de « means undetectable by an implementation » ? | > Et tu voudrais utiliser « volatile » ? Huh. | | Je sais pas, c'est pas un comme un alias de pointeur.
Aucun rapport.
| Le fait de définir la | notion d'alias n'implique pas forcément qu'on puisse les détecter, il me | semble.
Ah bon ?
| Pour revenir au volatile, il se peut que la machine cible définisse des | causes supplémentaires qui feraient qu'un tel accès serait indétectable,
le compilateur connaît la machyine cible. Donc, si elle définit quelque chose, cela ne lui est pas inconnu.
| selon qu'il y a des interruptions sur le système ou non, du multitache | concurrent (multiprocesseur, hyperthreading), ou encore de la mémoire | partagée. Ce sont autant de causes possibles d'accès indétectables (j'en | oublie certainement), et toutes ne sont pas nécessairement applicables à | tous les systèmes et, du coup, à toutes les implémentations.
Bah non, c'est pas ce qui est écrit.
-- Gaby
Gabriel Dos Reis
"Alain Naigeon" writes:
| "drkm" a écrit dans le message news: | | > 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 ». | | Tu poses le problème à l'envers :
Bah non.
| quand tu fais quelque chose pour optimiser, tu sais ce que tu fais,
qu'appelles-tu « optimiser » ?
| et tu sais quelles hypothèses tu fais | pour avoir le droit de le faire ; volatile te dit de considérer ces | hypothèses comme fausses.
Bah non, c'est pas ce qui est dit.
-- Gaby
"Alain Naigeon" <anaigeon@free.fr> writes:
| "drkm" <usenet.fclcxx@fgeorges.org> a écrit dans le message news:
| wkr7lg3n8u.fsf@fgeorges.org...
| > kanze@gabi-soft.fr 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 ».
|
| Tu poses le problème à l'envers :
Bah non.
| quand tu fais quelque chose pour optimiser, tu sais ce que tu fais,
qu'appelles-tu « optimiser » ?
| et tu sais quelles hypothèses tu fais
| pour avoir le droit de le faire ; volatile te dit de considérer ces
| hypothèses comme fausses.
| "drkm" a écrit dans le message news: | | > 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 ». | | Tu poses le problème à l'envers :
Bah non.
| quand tu fais quelque chose pour optimiser, tu sais ce que tu fais,
qu'appelles-tu « optimiser » ?
| et tu sais quelles hypothèses tu fais | pour avoir le droit de le faire ; volatile te dit de considérer ces | hypothèses comme fausses.
Bah non, c'est pas ce qui est dit.
-- Gaby
Christophe Lephay
"Gabriel Dos Reis" a écrit dans le message de news:
Bah non, c'est pas ce qui est écrit.
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.
Bref...
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
news: m3brckrcnf.fsf@uniton.integrable-solutions.net...
Bah non, c'est pas ce qui est écrit.
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.
"Gabriel Dos Reis" a écrit dans le message de news:
Bah non, c'est pas ce qui est écrit.
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.
Bref...
Alain Naigeon
"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.
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.
--
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" <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.
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.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
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.
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.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
drkm
"Alain Naigeon" writes:
Oui, la phrase est claire, aussi claire qu'elle puisse être dès lors qu'y figure le mot "implémentation".
?
Certaines modifs peuvent échapper à une implémentation (respectant la norme). La phrase dit que volatile est une demande de tenir compte de ce fait. Que le contenu concret soit extrêmement dépendant de la dite implémentation (et de son OS), c'est ce que dit bien la phrase elle-même.
Au contraire, il peut être indépendant de l'implémentation.
--drkm
"Alain Naigeon" <anaigeon@free.fr> writes:
Oui, la phrase est claire, aussi claire qu'elle puisse être dès lors
qu'y figure le mot "implémentation".
?
Certaines modifs peuvent
échapper à une implémentation (respectant la norme). La
phrase dit que volatile est une demande de tenir compte
de ce fait. Que le contenu concret soit extrêmement dépendant
de la dite implémentation (et de son OS), c'est ce que dit bien la
phrase elle-même.
Au contraire, il peut être indépendant de l'implémentation.
Oui, la phrase est claire, aussi claire qu'elle puisse être dès lors qu'y figure le mot "implémentation".
?
Certaines modifs peuvent échapper à une implémentation (respectant la norme). La phrase dit que volatile est une demande de tenir compte de ce fait. Que le contenu concret soit extrêmement dépendant de la dite implémentation (et de son OS), c'est ce que dit bien la phrase elle-même.
Au contraire, il peut être indépendant de l'implémentation.
--drkm
drkm
"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 ?
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 ?
--drkm
kanze
Jean-Marc Bourguet wrote:
writes:
[...]
Avec les threads Posix. Probablement avec les threads Windows aussi.
Mais on peut bien imaginer des modèles de thread où son utilisation
aurait un sens.
J'ai l'impression que plus le temps passe, moins on a de garantie et je ne vois pas de renversement de tendance.
Il faut voir. Jusqu'ici, les algorithmes sans lock et les systèmes multi-processeur n'ont pas eu d'importance, et avec les lock, et les garanties de Posix, sur des systèmes mono-processeur, on n'a pas besoin de volatile, autrement que sur le sig_atomic_t (qui ne sert dans la pratique que dans les systèmes mono-thread).
Je ne peux pas le vérifier, mais j'imagine que sur des processeurs embarqués, volatile a toujours un sens -- et les compilateurs font ce qu'il faut pour qu'il en ait. Je peux imaginer que si les algorithmes sans lock s'étendent, qu'il y ait une démande pour un volatile qui marche sur des processeurs généralistes. Mais ce n'est pas sûr -- j'imagine qu'il y aurait plutôt des « fonctions » (du genre atomic_incr ou compare_and_swap), et que ces fonctions donneront les mêmes garanties que phtread_mutex_lock en ce qui concerne la visibilité mémoire.
-- 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 wrote:
kanze@gabi-soft.fr writes:
[...]
Avec les threads Posix. Probablement avec les threads Windows
aussi.
Mais on peut bien imaginer des modèles de thread où son
utilisation
aurait un sens.
J'ai l'impression que plus le temps passe, moins on a de garantie et
je ne vois pas de renversement de tendance.
Il faut voir. Jusqu'ici, les algorithmes sans lock et les systèmes
multi-processeur n'ont pas eu d'importance, et avec les lock, et les
garanties de Posix, sur des systèmes mono-processeur, on n'a pas
besoin
de volatile, autrement que sur le sig_atomic_t (qui ne sert dans la
pratique que dans les systèmes mono-thread).
Je ne peux pas le vérifier, mais j'imagine que sur des processeurs
embarqués, volatile a toujours un sens -- et les compilateurs font ce
qu'il faut pour qu'il en ait. Je peux imaginer que si les algorithmes
sans lock s'étendent, qu'il y ait une démande pour un volatile qui
marche sur des processeurs généralistes. Mais ce n'est pas sûr --
j'imagine qu'il y aurait plutôt des « fonctions » (du genre
atomic_incr
ou compare_and_swap), et que ces fonctions donneront les mêmes
garanties
que phtread_mutex_lock en ce qui concerne la visibilité mémoire.
--
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
Avec les threads Posix. Probablement avec les threads Windows aussi.
Mais on peut bien imaginer des modèles de thread où son utilisation
aurait un sens.
J'ai l'impression que plus le temps passe, moins on a de garantie et je ne vois pas de renversement de tendance.
Il faut voir. Jusqu'ici, les algorithmes sans lock et les systèmes multi-processeur n'ont pas eu d'importance, et avec les lock, et les garanties de Posix, sur des systèmes mono-processeur, on n'a pas besoin de volatile, autrement que sur le sig_atomic_t (qui ne sert dans la pratique que dans les systèmes mono-thread).
Je ne peux pas le vérifier, mais j'imagine que sur des processeurs embarqués, volatile a toujours un sens -- et les compilateurs font ce qu'il faut pour qu'il en ait. Je peux imaginer que si les algorithmes sans lock s'étendent, qu'il y ait une démande pour un volatile qui marche sur des processeurs généralistes. Mais ce n'est pas sûr -- j'imagine qu'il y aurait plutôt des « fonctions » (du genre atomic_incr ou compare_and_swap), et que ces fonctions donneront les mêmes garanties que phtread_mutex_lock en ce qui concerne la visibilité mémoire.
-- 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
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.
En fait, à peu près tout ce qu'on peut dire de volatile, c'est que c'est un « accroche » où l'implémentation peut ajouter des garanties, si elle veut. L'intention est claire, d'après les exemples et d'autre texte non normatif, mais c'est aussi clair que rien n'est réelement exigé, pour la simple raison, je crois, qu'on ne sait pas formuler les exigeances d'une façon valable pour toute implémentation.
En attentant, si tu fais de la programmation bas niveau, par exemple des pilotes de périphérique ou sur des processeurs embarqués, tu es bien content de l'avoir.
-- 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
drkm wrote:
kanze@gabi-soft.fr 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.
En fait, à peu près tout ce qu'on peut dire de volatile, c'est que
c'est
un « accroche » où l'implémentation peut ajouter des garanties, si
elle
veut. L'intention est claire, d'après les exemples et d'autre texte
non
normatif, mais c'est aussi clair que rien n'est réelement exigé, pour
la
simple raison, je crois, qu'on ne sait pas formuler les exigeances
d'une
façon valable pour toute implémentation.
En attentant, si tu fais de la programmation bas niveau, par exemple
des
pilotes de périphérique ou sur des processeurs embarqués, tu es bien
content de l'avoir.
--
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
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.
En fait, à peu près tout ce qu'on peut dire de volatile, c'est que c'est un « accroche » où l'implémentation peut ajouter des garanties, si elle veut. L'intention est claire, d'après les exemples et d'autre texte non normatif, mais c'est aussi clair que rien n'est réelement exigé, pour la simple raison, je crois, qu'on ne sait pas formuler les exigeances d'une façon valable pour toute implémentation.
En attentant, si tu fais de la programmation bas niveau, par exemple des pilotes de périphérique ou sur des processeurs embarqués, tu es bien content de l'avoir.
-- 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
