dans l'article
, kanze à
a écrit le 14/03/06 8:45 :Ça veut dire quoi, état réel ? La valeur utilisée correspond
bien à l'état réel lors que la variable a été lue. Dans la
mesure où on modifie la variable de façon asynchrone par
ailleurs, on ne peut guère démander plus.
Une question a la con :-)
synchronisé un booleen cela a t'il un sens?
Meme si il est lu et ecris en meme temps, cela pose t'il
probleme (cas particulier du booleen)?
dans l'article
1142322316.752423.89240@j52g2000cwj.googlegroups.com, kanze à
kanze@gabi-soft.fr a écrit le 14/03/06 8:45 :
Ça veut dire quoi, état réel ? La valeur utilisée correspond
bien à l'état réel lors que la variable a été lue. Dans la
mesure où on modifie la variable de façon asynchrone par
ailleurs, on ne peut guère démander plus.
Une question a la con :-)
synchronisé un booleen cela a t'il un sens?
Meme si il est lu et ecris en meme temps, cela pose t'il
probleme (cas particulier du booleen)?
dans l'article
, kanze à
a écrit le 14/03/06 8:45 :Ça veut dire quoi, état réel ? La valeur utilisée correspond
bien à l'état réel lors que la variable a été lue. Dans la
mesure où on modifie la variable de façon asynchrone par
ailleurs, on ne peut guère démander plus.
Une question a la con :-)
synchronisé un booleen cela a t'il un sens?
Meme si il est lu et ecris en meme temps, cela pose t'il
probleme (cas particulier du booleen)?
kanze wrote on 14/03/2006 08:45:entre quel *temps* ?
Entre le temps qu'il a lu la valeur, et le temps qu'il en
utilise la copie, non ?
c'est ce que j'anticipe et crains, car la valeur _utilisée_
n'a plus aucune garantie d'être l'état réel.
Ça veut dire quoi, état réel ? [...]
tu as un problème avec ce qui n'est pas formulé par toi avec
tes mots ?
kanze wrote on 14/03/2006 08:45:
entre quel *temps* ?
Entre le temps qu'il a lu la valeur, et le temps qu'il en
utilise la copie, non ?
c'est ce que j'anticipe et crains, car la valeur _utilisée_
n'a plus aucune garantie d'être l'état réel.
Ça veut dire quoi, état réel ? [...]
tu as un problème avec ce qui n'est pas formulé par toi avec
tes mots ?
kanze wrote on 14/03/2006 08:45:entre quel *temps* ?
Entre le temps qu'il a lu la valeur, et le temps qu'il en
utilise la copie, non ?
c'est ce que j'anticipe et crains, car la valeur _utilisée_
n'a plus aucune garantie d'être l'état réel.
Ça veut dire quoi, état réel ? [...]
tu as un problème avec ce qui n'est pas formulé par toi avec
tes mots ?
Arnaud Meurgues wrote on 14/03/2006 13:46:Je crois qu'il veut surtout dire que « état réel » a une
sémantique floue en environnement multithread ou parallèle
et qu'il est bon de se poser à soi-même cette question afin
d'être sûr de savoir ce que l'on veut.
<troll>
est-ce propre à ce groupe ou seulement l'habitude de certains
que de faire de la sémantique pour la sémantique ?
quelle est "cette" question que soi-même devrait se poser ?
</troll>
btw, perso je ne "veux" rien et je n'aurais surement pas codé
une fonction qui fournit une information inutile (par durée de
vie incertaine);
cela n'empêchait pas d'alerter l'auteur sur les risques de non
pertinence de sa variable d'état; cela à été dit.
Arnaud Meurgues wrote on 14/03/2006 13:46:
Je crois qu'il veut surtout dire que « état réel » a une
sémantique floue en environnement multithread ou parallèle
et qu'il est bon de se poser à soi-même cette question afin
d'être sûr de savoir ce que l'on veut.
<troll>
est-ce propre à ce groupe ou seulement l'habitude de certains
que de faire de la sémantique pour la sémantique ?
quelle est "cette" question que soi-même devrait se poser ?
</troll>
btw, perso je ne "veux" rien et je n'aurais surement pas codé
une fonction qui fournit une information inutile (par durée de
vie incertaine);
cela n'empêchait pas d'alerter l'auteur sur les risques de non
pertinence de sa variable d'état; cela à été dit.
Arnaud Meurgues wrote on 14/03/2006 13:46:Je crois qu'il veut surtout dire que « état réel » a une
sémantique floue en environnement multithread ou parallèle
et qu'il est bon de se poser à soi-même cette question afin
d'être sûr de savoir ce que l'on veut.
<troll>
est-ce propre à ce groupe ou seulement l'habitude de certains
que de faire de la sémantique pour la sémantique ?
quelle est "cette" question que soi-même devrait se poser ?
</troll>
btw, perso je ne "veux" rien et je n'aurais surement pas codé
une fonction qui fournit une information inutile (par durée de
vie incertaine);
cela n'empêchait pas d'alerter l'auteur sur les risques de non
pertinence de sa variable d'état; cela à été dit.
Bruno CAUSSE wrote:je ne connais pas scoped_lock(), je vais voir cela.
Ce n'est pas une classe C++ standard.
James parle du principe RAII. RAII veut dire resource
acquisition is initialisation et c'est un idiome très utilisé
en C++.
Bruno CAUSSE wrote:
je ne connais pas scoped_lock(), je vais voir cela.
Ce n'est pas une classe C++ standard.
James parle du principe RAII. RAII veut dire resource
acquisition is initialisation et c'est un idiome très utilisé
en C++.
Bruno CAUSSE wrote:je ne connais pas scoped_lock(), je vais voir cela.
Ce n'est pas une classe C++ standard.
James parle du principe RAII. RAII veut dire resource
acquisition is initialisation et c'est un idiome très utilisé
en C++.
du coup, le volatile ne sert
plus a rien.
du coup, le volatile ne sert
plus a rien.
du coup, le volatile ne sert
plus a rien.
J'ai un problème avec ce qui est flou, et qui ne donne pas assez
de précisions pour pouvoir commencer à coder.
La question reste : dans cette contexte, qu'est-ce qu'on
entend par « l'état réel » ?
Je n'arrive pas à en donner une signification dans
cette contexte
a priori, il y a autant d'« états réels »
qu'il y a de threads
et le mot n'a de sens pour un thread donné
que dans la mesure où il accède à la variable.
(Et encore -- si plusieurs threads accèdent sans
synchronisation, on a en général un état indéfini.)
J'ai un problème avec ce qui est flou, et qui ne donne pas assez
de précisions pour pouvoir commencer à coder.
La question reste : dans cette contexte, qu'est-ce qu'on
entend par « l'état réel » ?
Je n'arrive pas à en donner une signification dans
cette contexte
a priori, il y a autant d'« états réels »
qu'il y a de threads
et le mot n'a de sens pour un thread donné
que dans la mesure où il accède à la variable.
(Et encore -- si plusieurs threads accèdent sans
synchronisation, on a en général un état indéfini.)
J'ai un problème avec ce qui est flou, et qui ne donne pas assez
de précisions pour pouvoir commencer à coder.
La question reste : dans cette contexte, qu'est-ce qu'on
entend par « l'état réel » ?
Je n'arrive pas à en donner une signification dans
cette contexte
a priori, il y a autant d'« états réels »
qu'il y a de threads
et le mot n'a de sens pour un thread donné
que dans la mesure où il accède à la variable.
(Et encore -- si plusieurs threads accèdent sans
synchronisation, on a en général un état indéfini.)
est-ce propre à ce groupe ou seulement l'habitude de certains
que de faire de la sémantique pour la sémantique ?
C'est le propre de certains d'entre nous de vouloir écrire un
code robuste, en comprenant ce qu'on fait.
quelle est "cette" question que soi-même devrait se poser ?
Pour commencer, qu'est-ce qu'on essaie de faire ?
btw, perso je ne "veux" rien et je n'aurais surement pas codé
une fonction qui fournit une information inutile (par durée de
vie incertaine);
La fonction, telle qu'elle est codée, est très utile. Elle
renvoie la valeur de la variable au moment t où elle est
appelée. À condition qu'il y a une synchronisation semblable
lors de l'écriture, elle remplit bien la fonction qu'elle est
sensée remplir.
cela n'empêchait pas d'alerter l'auteur sur les risques de non
pertinence de sa variable d'état; cela à été dit.
Quelles risques ? Tu ne les as toujours pas précisées.
Note bien que s'il renvoiait la variable par référence, la
situation serait différente. Mais ce n'était pas le cas.
est-ce propre à ce groupe ou seulement l'habitude de certains
que de faire de la sémantique pour la sémantique ?
C'est le propre de certains d'entre nous de vouloir écrire un
code robuste, en comprenant ce qu'on fait.
quelle est "cette" question que soi-même devrait se poser ?
Pour commencer, qu'est-ce qu'on essaie de faire ?
btw, perso je ne "veux" rien et je n'aurais surement pas codé
une fonction qui fournit une information inutile (par durée de
vie incertaine);
La fonction, telle qu'elle est codée, est très utile. Elle
renvoie la valeur de la variable au moment t où elle est
appelée. À condition qu'il y a une synchronisation semblable
lors de l'écriture, elle remplit bien la fonction qu'elle est
sensée remplir.
cela n'empêchait pas d'alerter l'auteur sur les risques de non
pertinence de sa variable d'état; cela à été dit.
Quelles risques ? Tu ne les as toujours pas précisées.
Note bien que s'il renvoiait la variable par référence, la
situation serait différente. Mais ce n'était pas le cas.
est-ce propre à ce groupe ou seulement l'habitude de certains
que de faire de la sémantique pour la sémantique ?
C'est le propre de certains d'entre nous de vouloir écrire un
code robuste, en comprenant ce qu'on fait.
quelle est "cette" question que soi-même devrait se poser ?
Pour commencer, qu'est-ce qu'on essaie de faire ?
btw, perso je ne "veux" rien et je n'aurais surement pas codé
une fonction qui fournit une information inutile (par durée de
vie incertaine);
La fonction, telle qu'elle est codée, est très utile. Elle
renvoie la valeur de la variable au moment t où elle est
appelée. À condition qu'il y a une synchronisation semblable
lors de l'écriture, elle remplit bien la fonction qu'elle est
sensée remplir.
cela n'empêchait pas d'alerter l'auteur sur les risques de non
pertinence de sa variable d'état; cela à été dit.
Quelles risques ? Tu ne les as toujours pas précisées.
Note bien que s'il renvoiait la variable par référence, la
situation serait différente. Mais ce n'était pas le cas.
kanze wrote on 15/03/2006 08:51:est-ce propre à ce groupe ou seulement l'habitude de
certains que de faire de la sémantique pour la sémantique ?
C'est le propre de certains d'entre nous de vouloir écrire
un code robuste, en comprenant ce qu'on fait.
on écrit du code là, ici, maintenant, dans ces conditions
gélatineuses sur l'usage de tel adjectif ou la place du'une
virgule ?
quelle est "cette" question que soi-même devrait se poser ?
Pour commencer, qu'est-ce qu'on essaie de faire ?
ben en ce moment, à part enculer les mouches, je vois pas ce
que "on" essaie de faire.
btw, perso je ne "veux" rien et je n'aurais surement pas
codé une fonction qui fournit une information inutile (par
durée de vie incertaine);
La fonction, telle qu'elle est codée, est très utile. Elle
renvoie la valeur de la variable au moment t où elle est
appelée. À condition qu'il y a une synchronisation semblable
lors de l'écriture, elle remplit bien la fonction qu'elle
est sensée remplir.
incorrect!
1- elle renvoie la valeur qu'à eu la variable "_interrupt" au
moment où elle a été accedé dans la méthode "isInterrupted";
entre cet instant d'évaluation et le moment "t" où la méthode
"isInterrupted" est appellée (tu as bien dit "la fonction ...
est appelée"), il s'écoule un temps indéterminable d'après les
informations fournis - par exemple si le lock est posé par une
autre méthode exécutée par un autre thread que celui réalisant
cet appel à "isInterrupted", le mutex.lock() suspendra cette
exécution, avec dans le pire des cas un deadlock qui
annihilira ton "t" qui ne surviendra jamais.
2- si la sémantique est importante à tes yeux - et si tous les
threads utilisant cet objet sont correctement synchronisés -
la fonction est mal codée et inutile car nécessairement cet
objet est "interrompu" (tous les threads manipulant cette
instance) par le lock dont c'est le but.
3- c'est toujours faux avec l'hypothèse d'une écriture
synchronizée car rien ne prémuni du déroulement suivant (temps
croissant de haut en bas)
| thread 1 thread 2
| call thr.isInterrupted()
| mutex.lock()
| mutex.lock()
| register bool state = _interrupt; (suspendu)
| mutex.unlock()
| (libéré)
| _interrupt = !_interrupt;
| ret
| mutex.unlock()
/ @myVariable = register
j'ai mis un "register" pour vous redonnez à moudre des "c'est
pas bien" ;-)
cela n'empêchait pas d'alerter l'auteur sur les risques de
non pertinence de sa variable d'état; cela à été dit.
Quelles risques ? Tu ne les as toujours pas précisées.
si tu n'as tjrs pas saisi, je n'y peux plus rien.
Note bien que s'il renvoiait la variable par référence, la
situation serait différente. Mais ce n'était pas le cas.
là j'ai un peu de mal à comprendre - peut être la sémantique,
ou la grammaire.
ce qui était "le cas" était un passage par référence d'une
variable devant contenir "l'état instantané" (un autre concept
flou); si ce n'est pas le cas, voulais-tu imaginer retourner
l'adresse de _interrupt ? dans les 2 cas, cela ne changera
rien.
kanze wrote on 15/03/2006 08:51:
est-ce propre à ce groupe ou seulement l'habitude de
certains que de faire de la sémantique pour la sémantique ?
C'est le propre de certains d'entre nous de vouloir écrire
un code robuste, en comprenant ce qu'on fait.
on écrit du code là, ici, maintenant, dans ces conditions
gélatineuses sur l'usage de tel adjectif ou la place du'une
virgule ?
quelle est "cette" question que soi-même devrait se poser ?
Pour commencer, qu'est-ce qu'on essaie de faire ?
ben en ce moment, à part enculer les mouches, je vois pas ce
que "on" essaie de faire.
btw, perso je ne "veux" rien et je n'aurais surement pas
codé une fonction qui fournit une information inutile (par
durée de vie incertaine);
La fonction, telle qu'elle est codée, est très utile. Elle
renvoie la valeur de la variable au moment t où elle est
appelée. À condition qu'il y a une synchronisation semblable
lors de l'écriture, elle remplit bien la fonction qu'elle
est sensée remplir.
incorrect!
1- elle renvoie la valeur qu'à eu la variable "_interrupt" au
moment où elle a été accedé dans la méthode "isInterrupted";
entre cet instant d'évaluation et le moment "t" où la méthode
"isInterrupted" est appellée (tu as bien dit "la fonction ...
est appelée"), il s'écoule un temps indéterminable d'après les
informations fournis - par exemple si le lock est posé par une
autre méthode exécutée par un autre thread que celui réalisant
cet appel à "isInterrupted", le mutex.lock() suspendra cette
exécution, avec dans le pire des cas un deadlock qui
annihilira ton "t" qui ne surviendra jamais.
2- si la sémantique est importante à tes yeux - et si tous les
threads utilisant cet objet sont correctement synchronisés -
la fonction est mal codée et inutile car nécessairement cet
objet est "interrompu" (tous les threads manipulant cette
instance) par le lock dont c'est le but.
3- c'est toujours faux avec l'hypothèse d'une écriture
synchronizée car rien ne prémuni du déroulement suivant (temps
croissant de haut en bas)
| thread 1 thread 2
| call thr.isInterrupted()
| mutex.lock()
| mutex.lock()
| register bool state = _interrupt; (suspendu)
| mutex.unlock()
| (libéré)
| _interrupt = !_interrupt;
| ret
| mutex.unlock()
/ @myVariable = register
j'ai mis un "register" pour vous redonnez à moudre des "c'est
pas bien" ;-)
cela n'empêchait pas d'alerter l'auteur sur les risques de
non pertinence de sa variable d'état; cela à été dit.
Quelles risques ? Tu ne les as toujours pas précisées.
si tu n'as tjrs pas saisi, je n'y peux plus rien.
Note bien que s'il renvoiait la variable par référence, la
situation serait différente. Mais ce n'était pas le cas.
là j'ai un peu de mal à comprendre - peut être la sémantique,
ou la grammaire.
ce qui était "le cas" était un passage par référence d'une
variable devant contenir "l'état instantané" (un autre concept
flou); si ce n'est pas le cas, voulais-tu imaginer retourner
l'adresse de _interrupt ? dans les 2 cas, cela ne changera
rien.
kanze wrote on 15/03/2006 08:51:est-ce propre à ce groupe ou seulement l'habitude de
certains que de faire de la sémantique pour la sémantique ?
C'est le propre de certains d'entre nous de vouloir écrire
un code robuste, en comprenant ce qu'on fait.
on écrit du code là, ici, maintenant, dans ces conditions
gélatineuses sur l'usage de tel adjectif ou la place du'une
virgule ?
quelle est "cette" question que soi-même devrait se poser ?
Pour commencer, qu'est-ce qu'on essaie de faire ?
ben en ce moment, à part enculer les mouches, je vois pas ce
que "on" essaie de faire.
btw, perso je ne "veux" rien et je n'aurais surement pas
codé une fonction qui fournit une information inutile (par
durée de vie incertaine);
La fonction, telle qu'elle est codée, est très utile. Elle
renvoie la valeur de la variable au moment t où elle est
appelée. À condition qu'il y a une synchronisation semblable
lors de l'écriture, elle remplit bien la fonction qu'elle
est sensée remplir.
incorrect!
1- elle renvoie la valeur qu'à eu la variable "_interrupt" au
moment où elle a été accedé dans la méthode "isInterrupted";
entre cet instant d'évaluation et le moment "t" où la méthode
"isInterrupted" est appellée (tu as bien dit "la fonction ...
est appelée"), il s'écoule un temps indéterminable d'après les
informations fournis - par exemple si le lock est posé par une
autre méthode exécutée par un autre thread que celui réalisant
cet appel à "isInterrupted", le mutex.lock() suspendra cette
exécution, avec dans le pire des cas un deadlock qui
annihilira ton "t" qui ne surviendra jamais.
2- si la sémantique est importante à tes yeux - et si tous les
threads utilisant cet objet sont correctement synchronisés -
la fonction est mal codée et inutile car nécessairement cet
objet est "interrompu" (tous les threads manipulant cette
instance) par le lock dont c'est le but.
3- c'est toujours faux avec l'hypothèse d'une écriture
synchronizée car rien ne prémuni du déroulement suivant (temps
croissant de haut en bas)
| thread 1 thread 2
| call thr.isInterrupted()
| mutex.lock()
| mutex.lock()
| register bool state = _interrupt; (suspendu)
| mutex.unlock()
| (libéré)
| _interrupt = !_interrupt;
| ret
| mutex.unlock()
/ @myVariable = register
j'ai mis un "register" pour vous redonnez à moudre des "c'est
pas bien" ;-)
cela n'empêchait pas d'alerter l'auteur sur les risques de
non pertinence de sa variable d'état; cela à été dit.
Quelles risques ? Tu ne les as toujours pas précisées.
si tu n'as tjrs pas saisi, je n'y peux plus rien.
Note bien que s'il renvoiait la variable par référence, la
situation serait différente. Mais ce n'était pas le cas.
là j'ai un peu de mal à comprendre - peut être la sémantique,
ou la grammaire.
ce qui était "le cas" était un passage par référence d'une
variable devant contenir "l'état instantané" (un autre concept
flou); si ce n'est pas le cas, voulais-tu imaginer retourner
l'adresse de _interrupt ? dans les 2 cas, cela ne changera
rien.
kanze wrote on 15/03/2006 08:46:a priori, il y a autant d'« états réels » qu'il y a de
threads
là j'aurais dit "états potentiellement distincts".
et le mot n'a de sens pour un thread donné que dans la
mesure où il accède à la variable.
s'il n'y accède pas, elle n'est pas d'état du tout ?
je ne pensais pas qu'un objet perdait ses membres non
consultés aussi facilement -- si le point est on se tape de
l'état de cette variable là, oui (et merci pour cette grande
clarification).
(Et encore -- si plusieurs threads accèdent sans
synchronisation, on a en général un état indéfini.)
c'est ce que j'ai énoncé il y a 15 posts et que tu refuses de
lire.
kanze wrote on 15/03/2006 08:46:
a priori, il y a autant d'« états réels » qu'il y a de
threads
là j'aurais dit "états potentiellement distincts".
et le mot n'a de sens pour un thread donné que dans la
mesure où il accède à la variable.
s'il n'y accède pas, elle n'est pas d'état du tout ?
je ne pensais pas qu'un objet perdait ses membres non
consultés aussi facilement -- si le point est on se tape de
l'état de cette variable là, oui (et merci pour cette grande
clarification).
(Et encore -- si plusieurs threads accèdent sans
synchronisation, on a en général un état indéfini.)
c'est ce que j'ai énoncé il y a 15 posts et que tu refuses de
lire.
kanze wrote on 15/03/2006 08:46:a priori, il y a autant d'« états réels » qu'il y a de
threads
là j'aurais dit "états potentiellement distincts".
et le mot n'a de sens pour un thread donné que dans la
mesure où il accède à la variable.
s'il n'y accède pas, elle n'est pas d'état du tout ?
je ne pensais pas qu'un objet perdait ses membres non
consultés aussi facilement -- si le point est on se tape de
l'état de cette variable là, oui (et merci pour cette grande
clarification).
(Et encore -- si plusieurs threads accèdent sans
synchronisation, on a en général un état indéfini.)
c'est ce que j'ai énoncé il y a 15 posts et que tu refuses de
lire.
