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.
Sylvain.
kanze
Sylvain wrote:
kanze wrote on 13/03/2006 10:32:
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 ? 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.
-- James Kanze GABI Software 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
Sylvain wrote:
kanze wrote on 13/03/2006 10:32:
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 ? 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.
--
James Kanze GABI Software
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
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 ? 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.
-- James Kanze GABI Software 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
Bruno CAUSSE
dans l'article , kanze à a écrit le 13/03/06 10:32 :
Certainement. C'est le principe du multi-thread. Tel que tu l'a écrit, la valeur du retour fait un « snapshot » du valeur instantanée de la variable.
Si c'est important que la valeur de _interrupt ne change pas pendant plus de temps, il faut prendre le lock à un niveau plus haut. Mais sache qu'il s'agit toujours d'une prise de vue «@instantanée ». Le thread qui modifie la variable a pû le faire tout de suite avant que tu prends le lock, ou tout de suite après que tu le libère ; il n'y a pas de déterminisme.
Vue les noms, j'imagine que tu « polles », c-à-d que tu appelles la fonction périodiquement pour savoir si ton thread a été interrompu. Alors... si la valeur de _interrupt change après que tu l'as lue, tu verras la nouvelle valeur la prochaine fois que tu polles. Le lock, ici, ne sert que pour garantir l'atomicité de la mise à jour et la synchronisation de la mémoire.
entre quel *temps* ?
Entre le temps qu'il a lu la valeur, et le temps qu'il en utilise la copie, non ?
Exact, mais j'ai compris tout cela 5 mn apres avoir posé la question. (il etait plus de minuit :)
dans l'article 1142242352.072027.81480@i40g2000cwc.googlegroups.com, kanze à
kanze@gabi-soft.fr a écrit le 13/03/06 10:32 :
Certainement. C'est le principe du multi-thread. Tel que tu l'a
écrit, la valeur du retour fait un « snapshot » du valeur
instantanée de la variable.
Si c'est important que la valeur de _interrupt ne change pas
pendant plus de temps, il faut prendre le lock à un niveau plus
haut. Mais sache qu'il s'agit toujours d'une prise de vue
«@instantanée ». Le thread qui modifie la variable a pû le
faire tout de suite avant que tu prends le lock, ou tout de
suite après que tu le libère ; il n'y a pas de déterminisme.
Vue les noms, j'imagine que tu « polles », c-à-d que tu appelles
la fonction périodiquement pour savoir si ton thread a été
interrompu. Alors... si la valeur de _interrupt change après que
tu l'as lue, tu verras la nouvelle valeur la prochaine fois que
tu polles. Le lock, ici, ne sert que pour garantir l'atomicité
de la mise à jour et la synchronisation de la mémoire.
entre quel *temps* ?
Entre le temps qu'il a lu la valeur, et le temps qu'il en
utilise la copie, non ?
Exact, mais j'ai compris tout cela 5 mn apres avoir posé la question. (il
etait plus de minuit :)
dans l'article , kanze à a écrit le 13/03/06 10:32 :
Certainement. C'est le principe du multi-thread. Tel que tu l'a écrit, la valeur du retour fait un « snapshot » du valeur instantanée de la variable.
Si c'est important que la valeur de _interrupt ne change pas pendant plus de temps, il faut prendre le lock à un niveau plus haut. Mais sache qu'il s'agit toujours d'une prise de vue «@instantanée ». Le thread qui modifie la variable a pû le faire tout de suite avant que tu prends le lock, ou tout de suite après que tu le libère ; il n'y a pas de déterminisme.
Vue les noms, j'imagine que tu « polles », c-à-d que tu appelles la fonction périodiquement pour savoir si ton thread a été interrompu. Alors... si la valeur de _interrupt change après que tu l'as lue, tu verras la nouvelle valeur la prochaine fois que tu polles. Le lock, ici, ne sert que pour garantir l'atomicité de la mise à jour et la synchronisation de la mémoire.
entre quel *temps* ?
Entre le temps qu'il a lu la valeur, et le temps qu'il en utilise la copie, non ?
Exact, mais j'ai compris tout cela 5 mn apres avoir posé la question. (il etait plus de minuit :)
Bruno CAUSSE
dans l'article , kanze à a écrit le 13/03/06 10:40 :
Probablement, mais il me semble qu'une solution avec un scoped_lock serait encore préférable :
Pas la peine de declarer la variable -- le compilateur copierait la valeur de retour quelque part avant d'appeler le destructeur de scoped_lock (qui lui libèrera le lock que le constructeur a pris).
je ne connais pas scoped_lock(), je vais voir cela.
dans l'article 1142242802.800842.147200@j52g2000cwj.googlegroups.com, kanze
à kanze@gabi-soft.fr a écrit le 13/03/06 10:40 :
Probablement, mais il me semble qu'une solution avec un
scoped_lock serait encore préférable :
Pas la peine de declarer la variable -- le compilateur copierait
la valeur de retour quelque part avant d'appeler le destructeur
de scoped_lock (qui lui libèrera le lock que le constructeur a
pris).
je ne connais pas scoped_lock(), je vais voir cela.
Pas la peine de declarer la variable -- le compilateur copierait la valeur de retour quelque part avant d'appeler le destructeur de scoped_lock (qui lui libèrera le lock que le constructeur a pris).
je ne connais pas scoped_lock(), je vais voir cela.
Bruno CAUSSE
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)?
Arnaud Meurgues
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++.
Il consiste à utiliser le constructeur d'une classe pour allouer une resource et son destructeur pour la libérer. De cette manière, on est certain de ne pas oublier la libération de la resource (par exemple en cas d'exception ou si (bien que ce ne soit pas recommandé) on a plusieurs return possible pour sortir d'une fonction).
On utilise le fait qu'une variable automatique est obligatoirement détruite en sortie de scope (à la première accolade fermante).
Ainsi, la classe scoped_lock devrait être quelque chose du genre :
struct scoped_lock { scoped_lock(mutex_t& mutex) : myMutex(mutex) { myMutex.lock(); } ~scoped_lock() { myMutex.unlock(); } private: mutex_t& myMutex; scoped_lock(scoped_lock&); // pas de copie possible };
-- Arnaud
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++.
Il consiste à utiliser le constructeur d'une classe pour allouer une
resource et son destructeur pour la libérer. De cette manière, on est
certain de ne pas oublier la libération de la resource (par exemple en
cas d'exception ou si (bien que ce ne soit pas recommandé) on a
plusieurs return possible pour sortir d'une fonction).
On utilise le fait qu'une variable automatique est obligatoirement
détruite en sortie de scope (à la première accolade fermante).
Ainsi, la classe scoped_lock devrait être quelque chose du genre :
struct scoped_lock {
scoped_lock(mutex_t& mutex) : myMutex(mutex) { myMutex.lock(); }
~scoped_lock() { myMutex.unlock(); }
private:
mutex_t& myMutex;
scoped_lock(scoped_lock&); // pas de copie possible
};
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++.
Il consiste à utiliser le constructeur d'une classe pour allouer une resource et son destructeur pour la libérer. De cette manière, on est certain de ne pas oublier la libération de la resource (par exemple en cas d'exception ou si (bien que ce ne soit pas recommandé) on a plusieurs return possible pour sortir d'une fonction).
On utilise le fait qu'une variable automatique est obligatoirement détruite en sortie de scope (à la première accolade fermante).
Ainsi, la classe scoped_lock devrait être quelque chose du genre :
struct scoped_lock { scoped_lock(mutex_t& mutex) : myMutex(mutex) { myMutex.lock(); } ~scoped_lock() { myMutex.unlock(); } private: mutex_t& myMutex; scoped_lock(scoped_lock&); // pas de copie possible };
-- Arnaud
Bruno CAUSSE
dans l'article 44168a19$0$21524$, Arnaud Meurgues à a écrit le 14/03/06 10:17 :
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++.
Il consiste à utiliser le constructeur d'une classe pour allouer une resource et son destructeur pour la libérer. De cette manière, on est certain de ne pas oublier la libération de la resource (par exemple en cas d'exception ou si (bien que ce ne soit pas recommandé) on a plusieurs return possible pour sortir d'une fonction).
On utilise le fait qu'une variable automatique est obligatoirement détruite en sortie de scope (à la première accolade fermante).
Ainsi, la classe scoped_lock devrait être quelque chose du genre :
struct scoped_lock { scoped_lock(mutex_t& mutex) : myMutex(mutex) { myMutex.lock(); } ~scoped_lock() { myMutex.unlock(); } private: mutex_t& myMutex; scoped_lock(scoped_lock&); // pas de copie possible };
je vois, merci.
dans l'article 44168a19$0$21524$626a54ce@news.free.fr, Arnaud Meurgues à
news.arnaud@meurgues.non.fr.invalid a écrit le 14/03/06 10:17 :
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++.
Il consiste à utiliser le constructeur d'une classe pour allouer une
resource et son destructeur pour la libérer. De cette manière, on est
certain de ne pas oublier la libération de la resource (par exemple en
cas d'exception ou si (bien que ce ne soit pas recommandé) on a
plusieurs return possible pour sortir d'une fonction).
On utilise le fait qu'une variable automatique est obligatoirement
détruite en sortie de scope (à la première accolade fermante).
Ainsi, la classe scoped_lock devrait être quelque chose du genre :
struct scoped_lock {
scoped_lock(mutex_t& mutex) : myMutex(mutex) { myMutex.lock(); }
~scoped_lock() { myMutex.unlock(); }
private:
mutex_t& myMutex;
scoped_lock(scoped_lock&); // pas de copie possible
};
dans l'article 44168a19$0$21524$, Arnaud Meurgues à a écrit le 14/03/06 10:17 :
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++.
Il consiste à utiliser le constructeur d'une classe pour allouer une resource et son destructeur pour la libérer. De cette manière, on est certain de ne pas oublier la libération de la resource (par exemple en cas d'exception ou si (bien que ce ne soit pas recommandé) on a plusieurs return possible pour sortir d'une fonction).
On utilise le fait qu'une variable automatique est obligatoirement détruite en sortie de scope (à la première accolade fermante).
Ainsi, la classe scoped_lock devrait être quelque chose du genre :
struct scoped_lock { scoped_lock(mutex_t& mutex) : myMutex(mutex) { myMutex.lock(); } ~scoped_lock() { myMutex.unlock(); } private: mutex_t& myMutex; scoped_lock(scoped_lock&); // pas de copie possible };
je vois, merci.
Sylvain
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 ?
Sylvain.
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 ?
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 ?
Sylvain.
Arnaud Meurgues
Sylvain wrote:
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 ?
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.
-- Arnaud
Sylvain wrote:
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 ?
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.
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 ?
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.
-- Arnaud
Sylvain
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.
Sylvain.
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.
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.
