|> > |> Ou comme l'introduction de « volatile » avec la sémantique |> > |> qu'un objet déclaré avec un type volatile pourrait voir sa |> > |> valeur modifiée de manière inconnue au compilateur ou pourrait |> > |> avoir d'autres « side effects » inconnus ? C'est vachement |> > |> plus de vérification et de rigeur ça.
|> > Je ne sais pas. Je n'ai pas vu d'autres alternatifs. Dans la |> > pratique, volatile m'a été assez utile dans les cas qui |> > correspondaient à son utilisation voulue.
|> Il y a eu dans le DDJ (en deux parties, juillet et août 2004, je |> pense) un article de Meyers et Alexandrescu sur C++ et le |> Double-Checked Locking Pattern. Je ne l'ai pas sous la main, mais il |> parlait notamment de volatile et de son inutilisabilité. Je ne me |> souviens pas des détails, mais il ne m'a pas semblé que ces |> problèmes étaient spécifiques au C++.
Je n'ai pas vu l'article, mais je peux imaginer le teneur. Scott m'avais démandé mon avis sur une présentation qu'il allait faire avec Andrei il y a six mois, environ, et on a eu une discussion assez détaillée.
Volatile ne sert effectivement à rien dans le threading. Pour deux raisons : premièrement, ce n'est pas pour ça qu'il a été conçu, et deuxièmement, les fournisseurs de compilateurs ont décidé de ne pas l'étendre à cette utilisation.
|> Il me semble que la conclusion était qu'il n'était d'aucune |> utilité dans ce cas. Voire en général. Je rappelle que je ne me |> souviens pas des détails, mais je peux retrouver l'article, si |> nécessaire.
Ce n'est pas la peine, étant donné que la critique que Scott fait de volatile, c'est moi qui lui l'a donné.
Volatile est très utile dans les cas où il est utile. C-à-d, en général, dans les cas pour lesquels il a été conçu, et quand les fournisseurs de compilateurs le prenent en compte. En général, les compilateurs sur des machines générales ne le prenent pas vraiment en compte, parce qu'il n'a rien d'intéressant à faire dans un programme dans l'espace utilisateur. En revanche, quand j'écrivais des pilotes de périphérique, j'étais bien content de l'avoir.
|> Je n'ai jamais très bien cerné les garanties que donne la norme à |> propos de volatile, et donc de ses utilisations possibles. Qu'en |> est-il réellement ?
La norme ne garantit pas grand chose, en effet. Exprès, parce que toutes les utilisations sont assez près du hardware. Mais quand tu fais des entrées/sorties mappées mémoire, sur un processeur embarqué primatif (comparé à un Sparc ou à un PC moderne), c'est extrèmement utile. Donc, par exemple, sur un controlleur de ligne série que je connaissais, pour commencer l'initialisation, il fallait écrire trois fois un 0 dans la porte de contrôle. Ce qui se présentait en C comme : *p = 0 ; *p = 0 ; *p = 0 ; Même à l'époque, avec l'optimisation on ne peut plus primitive, le compilateur reconnaissait qu'il pouvait supprimer les deux premières affectations. À moins que p soit déclaré unsigned char volatile*.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
drkm <usenet.fclcxx@fgeorges.org> writes:
|> James Kanze <james.kanze@free.fr> writes:
|> > Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|> > |> Ou comme l'introduction de « volatile » avec la sémantique
|> > |> qu'un objet déclaré avec un type volatile pourrait voir sa
|> > |> valeur modifiée de manière inconnue au compilateur ou pourrait
|> > |> avoir d'autres « side effects » inconnus ? C'est vachement
|> > |> plus de vérification et de rigeur ça.
|> > Je ne sais pas. Je n'ai pas vu d'autres alternatifs. Dans la
|> > pratique, volatile m'a été assez utile dans les cas qui
|> > correspondaient à son utilisation voulue.
|> Il y a eu dans le DDJ (en deux parties, juillet et août 2004, je
|> pense) un article de Meyers et Alexandrescu sur C++ et le
|> Double-Checked Locking Pattern. Je ne l'ai pas sous la main, mais il
|> parlait notamment de volatile et de son inutilisabilité. Je ne me
|> souviens pas des détails, mais il ne m'a pas semblé que ces
|> problèmes étaient spécifiques au C++.
Je n'ai pas vu l'article, mais je peux imaginer le teneur. Scott m'avais
démandé mon avis sur une présentation qu'il allait faire avec Andrei il
y a six mois, environ, et on a eu une discussion assez détaillée.
Volatile ne sert effectivement à rien dans le threading. Pour deux
raisons : premièrement, ce n'est pas pour ça qu'il a été conçu, et
deuxièmement, les fournisseurs de compilateurs ont décidé de ne pas
l'étendre à cette utilisation.
|> Il me semble que la conclusion était qu'il n'était d'aucune
|> utilité dans ce cas. Voire en général. Je rappelle que je ne me
|> souviens pas des détails, mais je peux retrouver l'article, si
|> nécessaire.
Ce n'est pas la peine, étant donné que la critique que Scott fait de
volatile, c'est moi qui lui l'a donné.
Volatile est très utile dans les cas où il est utile. C-à-d, en général,
dans les cas pour lesquels il a été conçu, et quand les fournisseurs de
compilateurs le prenent en compte. En général, les compilateurs sur des
machines générales ne le prenent pas vraiment en compte, parce qu'il n'a
rien d'intéressant à faire dans un programme dans l'espace utilisateur.
En revanche, quand j'écrivais des pilotes de périphérique, j'étais bien
content de l'avoir.
|> Je n'ai jamais très bien cerné les garanties que donne la norme à
|> propos de volatile, et donc de ses utilisations possibles. Qu'en
|> est-il réellement ?
La norme ne garantit pas grand chose, en effet. Exprès, parce que toutes
les utilisations sont assez près du hardware. Mais quand tu fais des
entrées/sorties mappées mémoire, sur un processeur embarqué primatif
(comparé à un Sparc ou à un PC moderne), c'est extrèmement utile. Donc,
par exemple, sur un controlleur de ligne série que je connaissais, pour
commencer l'initialisation, il fallait écrire trois fois un 0 dans la
porte de contrôle. Ce qui se présentait en C comme :
*p = 0 ;
*p = 0 ;
*p = 0 ;
Même à l'époque, avec l'optimisation on ne peut plus primitive, le
compilateur reconnaissait qu'il pouvait supprimer les deux premières
affectations. À moins que p soit déclaré unsigned char volatile*.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > |> Ou comme l'introduction de « volatile » avec la sémantique |> > |> qu'un objet déclaré avec un type volatile pourrait voir sa |> > |> valeur modifiée de manière inconnue au compilateur ou pourrait |> > |> avoir d'autres « side effects » inconnus ? C'est vachement |> > |> plus de vérification et de rigeur ça.
|> > Je ne sais pas. Je n'ai pas vu d'autres alternatifs. Dans la |> > pratique, volatile m'a été assez utile dans les cas qui |> > correspondaient à son utilisation voulue.
|> Il y a eu dans le DDJ (en deux parties, juillet et août 2004, je |> pense) un article de Meyers et Alexandrescu sur C++ et le |> Double-Checked Locking Pattern. Je ne l'ai pas sous la main, mais il |> parlait notamment de volatile et de son inutilisabilité. Je ne me |> souviens pas des détails, mais il ne m'a pas semblé que ces |> problèmes étaient spécifiques au C++.
Je n'ai pas vu l'article, mais je peux imaginer le teneur. Scott m'avais démandé mon avis sur une présentation qu'il allait faire avec Andrei il y a six mois, environ, et on a eu une discussion assez détaillée.
Volatile ne sert effectivement à rien dans le threading. Pour deux raisons : premièrement, ce n'est pas pour ça qu'il a été conçu, et deuxièmement, les fournisseurs de compilateurs ont décidé de ne pas l'étendre à cette utilisation.
|> Il me semble que la conclusion était qu'il n'était d'aucune |> utilité dans ce cas. Voire en général. Je rappelle que je ne me |> souviens pas des détails, mais je peux retrouver l'article, si |> nécessaire.
Ce n'est pas la peine, étant donné que la critique que Scott fait de volatile, c'est moi qui lui l'a donné.
Volatile est très utile dans les cas où il est utile. C-à-d, en général, dans les cas pour lesquels il a été conçu, et quand les fournisseurs de compilateurs le prenent en compte. En général, les compilateurs sur des machines générales ne le prenent pas vraiment en compte, parce qu'il n'a rien d'intéressant à faire dans un programme dans l'espace utilisateur. En revanche, quand j'écrivais des pilotes de périphérique, j'étais bien content de l'avoir.
|> Je n'ai jamais très bien cerné les garanties que donne la norme à |> propos de volatile, et donc de ses utilisations possibles. Qu'en |> est-il réellement ?
La norme ne garantit pas grand chose, en effet. Exprès, parce que toutes les utilisations sont assez près du hardware. Mais quand tu fais des entrées/sorties mappées mémoire, sur un processeur embarqué primatif (comparé à un Sparc ou à un PC moderne), c'est extrèmement utile. Donc, par exemple, sur un controlleur de ligne série que je connaissais, pour commencer l'initialisation, il fallait écrire trois fois un 0 dans la porte de contrôle. Ce qui se présentait en C comme : *p = 0 ; *p = 0 ; *p = 0 ; Même à l'époque, avec l'optimisation on ne peut plus primitive, le compilateur reconnaissait qu'il pouvait supprimer les deux premières affectations. À moins que p soit déclaré unsigned char volatile*.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Emmanuel Delahaye
James Kanze wrote on 11/11/04 :
<volatile>
En revanche, quand j'écrivais des pilotes de périphérique, j'étais bien content de l'avoir.
Absolument.
entrées/sorties mappées mémoire, sur un processeur embarqué primatif
'primaire' ou 'primitif' !
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
James Kanze wrote on 11/11/04 :
<volatile>
En revanche, quand j'écrivais des pilotes de périphérique, j'étais bien
content de l'avoir.
Absolument.
entrées/sorties mappées mémoire, sur un processeur embarqué primatif
'primaire' ou 'primitif' !
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
En revanche, quand j'écrivais des pilotes de périphérique, j'étais bien content de l'avoir.
Absolument.
entrées/sorties mappées mémoire, sur un processeur embarqué primatif
'primaire' ou 'primitif' !
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Gabriel Dos Reis
cedric writes:
| Gabriel Dos Reis wrote: | > Non, on ne sait pas ce qu'il fait : il peut avoir des « unknowns side | > effects », par exemple établir une commnication avec l'Alpha du | > Centaure. | | Le compilateur ne sait pas ce qu'il fait, craint qu'il entre en
Il n'y a pas que le compilateur qui est concerné par la sémantique du programme. Par exemple, comment un vérificateur de programme fait pour savoir que le code généré par le compilateur a la bonne sémantique ? D'après la définition de « volatile », rien n'empêche un compilateur d'invoquer « unknown side effects » pour couvrir ses propres bogues de traduction.
| communication avec alpha du centaure, et donc, ne sachant pas comment | optimiser cette communication potentielle, s'en tiens à ce que le | programmeur, qui lui sait ce qui se passe, à écrit dans son source.
Oui, mais quelle la sémantique du programme résultant ?
| Faut arreter la coke.
Tu parles sûrement de l'interface entre ton clavier et ta chaise ?
-- Gaby
cedric <rixed@happyleptic.NOSPAM.org> writes:
| Gabriel Dos Reis wrote:
| > Non, on ne sait pas ce qu'il fait : il peut avoir des « unknowns side
| > effects », par exemple établir une commnication avec l'Alpha du
| > Centaure.
|
| Le compilateur ne sait pas ce qu'il fait, craint qu'il entre en
Il n'y a pas que le compilateur qui est concerné par la sémantique du
programme. Par exemple, comment un vérificateur de programme fait pour
savoir que le code généré par le compilateur a la bonne sémantique ?
D'après la définition de « volatile », rien n'empêche un compilateur
d'invoquer « unknown side effects » pour couvrir ses propres bogues de
traduction.
| communication avec alpha du centaure, et donc, ne sachant pas comment
| optimiser cette communication potentielle, s'en tiens à ce que le
| programmeur, qui lui sait ce qui se passe, à écrit dans son source.
Oui, mais quelle la sémantique du programme résultant ?
| Faut arreter la coke.
Tu parles sûrement de l'interface entre ton clavier et ta chaise ?
| Gabriel Dos Reis wrote: | > Non, on ne sait pas ce qu'il fait : il peut avoir des « unknowns side | > effects », par exemple établir une commnication avec l'Alpha du | > Centaure. | | Le compilateur ne sait pas ce qu'il fait, craint qu'il entre en
Il n'y a pas que le compilateur qui est concerné par la sémantique du programme. Par exemple, comment un vérificateur de programme fait pour savoir que le code généré par le compilateur a la bonne sémantique ? D'après la définition de « volatile », rien n'empêche un compilateur d'invoquer « unknown side effects » pour couvrir ses propres bogues de traduction.
| communication avec alpha du centaure, et donc, ne sachant pas comment | optimiser cette communication potentielle, s'en tiens à ce que le | programmeur, qui lui sait ce qui se passe, à écrit dans son source.
Oui, mais quelle la sémantique du programme résultant ?
| Faut arreter la coke.
Tu parles sûrement de l'interface entre ton clavier et ta chaise ?
-- Gaby
Gabriel Dos Reis
drkm writes:
[...]
| Je n'ai jamais très bien cerné les garanties que donne la norme à | propos de volatile, et donc de ses utilisations possibles. Qu'en | est-il réellement ?
Un trou noir.
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
[...]
| Je n'ai jamais très bien cerné les garanties que donne la norme à
| propos de volatile, et donc de ses utilisations possibles. Qu'en
| est-il réellement ?
| Je n'ai jamais très bien cerné les garanties que donne la norme à | propos de volatile, et donc de ses utilisations possibles. Qu'en | est-il réellement ?
Un trou noir.
-- Gaby
cedric
Gabriel Dos Reis wrote:
Il n'y a pas que le compilateur qui est concerné par la sémantique du programme. Par exemple, comment un vérificateur de programme fait pour savoir que le code généré par le compilateur a la bonne sémantique ?
Clairement, il ne peut pas en se basant uniquement sur le programme. C'est implémentation-defined. Si j'ai bien compris, tu reproches à la norme d'autoriser à priori une implémentation à faire ce qu'elle veut y compris aux objets non volatiles du programme lorsqu'on accède à un objet volatile, c'est bien cela ? Et que donc, on ne peut pas garantir que le compilateur est buggé si un dragon sonne à la porte lorsqu'on accède à un objet volatile ?
Bon, mais si on ajoute à la sémantique du programme la sémantique de la documentation du compilo et de l'architecture, alors tout rentre dans l'ordre et les dragons seront biens gardés, non ?
| Faut arreter la coke.
Tu parles sûrement de l'interface entre ton clavier et ta chaise ?
Moi aussi f.m.e me manque...
Gabriel Dos Reis wrote:
Il n'y a pas que le compilateur qui est concerné par la sémantique du
programme. Par exemple, comment un vérificateur de programme fait pour
savoir que le code généré par le compilateur a la bonne sémantique ?
Clairement, il ne peut pas en se basant uniquement sur le programme.
C'est implémentation-defined.
Si j'ai bien compris, tu reproches à la norme d'autoriser à priori une
implémentation à faire ce qu'elle veut y compris aux objets non
volatiles du programme lorsqu'on accède à un objet volatile, c'est bien
cela ? Et que donc, on ne peut pas garantir que le compilateur est buggé
si un dragon sonne à la porte lorsqu'on accède à un objet volatile ?
Bon, mais si on ajoute à la sémantique du programme la sémantique de la
documentation du compilo et de l'architecture, alors tout rentre dans
l'ordre et les dragons seront biens gardés, non ?
| Faut arreter la coke.
Tu parles sûrement de l'interface entre ton clavier et ta chaise ?
Il n'y a pas que le compilateur qui est concerné par la sémantique du programme. Par exemple, comment un vérificateur de programme fait pour savoir que le code généré par le compilateur a la bonne sémantique ?
Clairement, il ne peut pas en se basant uniquement sur le programme. C'est implémentation-defined. Si j'ai bien compris, tu reproches à la norme d'autoriser à priori une implémentation à faire ce qu'elle veut y compris aux objets non volatiles du programme lorsqu'on accède à un objet volatile, c'est bien cela ? Et que donc, on ne peut pas garantir que le compilateur est buggé si un dragon sonne à la porte lorsqu'on accède à un objet volatile ?
Bon, mais si on ajoute à la sémantique du programme la sémantique de la documentation du compilo et de l'architecture, alors tout rentre dans l'ordre et les dragons seront biens gardés, non ?
| Faut arreter la coke.
Tu parles sûrement de l'interface entre ton clavier et ta chaise ?
Moi aussi f.m.e me manque...
Gabriel Dos Reis
cedric writes:
| Gabriel Dos Reis wrote: | > Il n'y a pas que le compilateur qui est concerné par la sémantique du | > programme. Par exemple, comment un vérificateur de programme fait pour | > savoir que le code généré par le compilateur a la bonne sémantique ? | | Clairement, il ne peut pas en se basant uniquement sur le | programme. C'est implémentation-defined.
Si certains « side-effects » sont inconnus de l'implémentation, cela ne peut pas être « implementation-defined ».
| Si j'ai bien compris, tu reproches à la norme d'autoriser à priori une | implémentation à faire ce qu'elle veut y compris aux objets non | volatiles du programme lorsqu'on accède à un objet volatile, c'est | bien cela ?
Non.
je reproche au comité ANSI d'avoir inventé un trou noir. Un machin qui donne à un programme C qui l'utilise, *n'importe quelle* sémantique.
| Et que donc, on ne peut pas garantir que le compilateur | est buggé si un dragon sonne à la porte lorsqu'on accède à un objet | volatile ?
Pas « one ne peut pas garantir », mais on ne peut pas vérifier raisonnablement que le compilateur fait quelque chose de raisonnable -- google un peu et regarde la longueur et la teneur des fils sur volatile.
| Bon, mais si on ajoute à la sémantique du programme la sémantique de | la documentation du compilo et de l'architecture, alors tout rentre | dans l'ordre et les dragons seront biens gardés, non ?
Non.
-- Gaby
cedric <rixed@happyleptic.NOSPAM.org> writes:
| Gabriel Dos Reis wrote:
| > Il n'y a pas que le compilateur qui est concerné par la sémantique du
| > programme. Par exemple, comment un vérificateur de programme fait pour
| > savoir que le code généré par le compilateur a la bonne sémantique ?
|
| Clairement, il ne peut pas en se basant uniquement sur le
| programme. C'est implémentation-defined.
Si certains « side-effects » sont inconnus de l'implémentation, cela
ne peut pas être « implementation-defined ».
| Si j'ai bien compris, tu reproches à la norme d'autoriser à priori une
| implémentation à faire ce qu'elle veut y compris aux objets non
| volatiles du programme lorsqu'on accède à un objet volatile, c'est
| bien cela ?
Non.
je reproche au comité ANSI d'avoir inventé un trou noir.
Un machin qui donne à un programme C qui l'utilise, *n'importe quelle*
sémantique.
| Et que donc, on ne peut pas garantir que le compilateur
| est buggé si un dragon sonne à la porte lorsqu'on accède à un objet
| volatile ?
Pas « one ne peut pas garantir », mais on ne peut pas vérifier
raisonnablement que le compilateur fait quelque chose de raisonnable
-- google un peu et regarde la longueur et la teneur des fils sur volatile.
| Bon, mais si on ajoute à la sémantique du programme la sémantique de
| la documentation du compilo et de l'architecture, alors tout rentre
| dans l'ordre et les dragons seront biens gardés, non ?
| Gabriel Dos Reis wrote: | > Il n'y a pas que le compilateur qui est concerné par la sémantique du | > programme. Par exemple, comment un vérificateur de programme fait pour | > savoir que le code généré par le compilateur a la bonne sémantique ? | | Clairement, il ne peut pas en se basant uniquement sur le | programme. C'est implémentation-defined.
Si certains « side-effects » sont inconnus de l'implémentation, cela ne peut pas être « implementation-defined ».
| Si j'ai bien compris, tu reproches à la norme d'autoriser à priori une | implémentation à faire ce qu'elle veut y compris aux objets non | volatiles du programme lorsqu'on accède à un objet volatile, c'est | bien cela ?
Non.
je reproche au comité ANSI d'avoir inventé un trou noir. Un machin qui donne à un programme C qui l'utilise, *n'importe quelle* sémantique.
| Et que donc, on ne peut pas garantir que le compilateur | est buggé si un dragon sonne à la porte lorsqu'on accède à un objet | volatile ?
Pas « one ne peut pas garantir », mais on ne peut pas vérifier raisonnablement que le compilateur fait quelque chose de raisonnable -- google un peu et regarde la longueur et la teneur des fils sur volatile.
| Bon, mais si on ajoute à la sémantique du programme la sémantique de | la documentation du compilo et de l'architecture, alors tout rentre | dans l'ordre et les dragons seront biens gardés, non ?
Non.
-- Gaby
cedric
Gabriel Dos Reis wrote:
-- google un peu et regarde la longueur et la teneur des fils sur volatile.
C'est ce que je vais faire. Merci.
Gabriel Dos Reis wrote:
-- google un peu et regarde la longueur et la teneur des fils sur volatile.
