Ici, une autre fonction peut modifier b[a] en même temps. je ne pensais pas a ca (b est const en realité)
mais si un deuxieme objet appele la methode pendant q'un autre l' utilise partagent t'ils le meme a et c?
-- Bruno Causse http://perso.wanadoo.fr/othello
Bruno Jouhier
"Bruno Causse" a écrit dans le message de news: 1h86gmc.y5hu8u3ops3cN%
Fabien LE LEZ wrote:
Ici, une autre fonction peut modifier b[a] en même temps. je ne pensais pas a ca (b est const en realité)
mais si un deuxieme objet appele la methode pendant q'un autre l' utilise partagent t'ils le meme a et c?
Non. Chaque thread a sa propre pile pour les variables locales et le passage de paramètres. Pas de risque d'interférences ici.
Si b est const, ce code est parfaitement sûr.
Si b ne l'est pas, ça reste en fait thread safe car tu as un seul accès à b[a] dans ta méthode et car les types manipulés (référence sur le tableau et int) sont gérés de manière atomique par la VM. Si tu utilisais 2 fois b[a] dans ta méthode, ça ne serait plus thread safe il y aurait un risque de modif de b[a] en cours de méthode, et donc un comportement non déterministe.
Bruno
-- Bruno Causse http://perso.wanadoo.fr/othello
"Bruno Causse" <pasde.hcyrano.spam@free.fr> a écrit dans le message de news:
1h86gmc.y5hu8u3ops3cN%pasde.hcyrano.spam@free.fr...
Fabien LE LEZ <gramster@gramster.com> wrote:
Ici, une autre fonction peut modifier b[a] en même temps.
je ne pensais pas a ca (b est const en realité)
mais si un deuxieme objet appele la methode pendant q'un autre l'
utilise partagent t'ils le meme a et c?
Non. Chaque thread a sa propre pile pour les variables locales et le passage
de paramètres. Pas de risque d'interférences ici.
Si b est const, ce code est parfaitement sûr.
Si b ne l'est pas, ça reste en fait thread safe car tu as un seul accès à
b[a] dans ta méthode et car les types manipulés (référence sur le tableau et
int) sont gérés de manière atomique par la VM. Si tu utilisais 2 fois b[a]
dans ta méthode, ça ne serait plus thread safe il y aurait un risque de
modif de b[a] en cours de méthode, et donc un comportement non déterministe.
"Bruno Causse" a écrit dans le message de news: 1h86gmc.y5hu8u3ops3cN%
Fabien LE LEZ wrote:
Ici, une autre fonction peut modifier b[a] en même temps. je ne pensais pas a ca (b est const en realité)
mais si un deuxieme objet appele la methode pendant q'un autre l' utilise partagent t'ils le meme a et c?
Non. Chaque thread a sa propre pile pour les variables locales et le passage de paramètres. Pas de risque d'interférences ici.
Si b est const, ce code est parfaitement sûr.
Si b ne l'est pas, ça reste en fait thread safe car tu as un seul accès à b[a] dans ta méthode et car les types manipulés (référence sur le tableau et int) sont gérés de manière atomique par la VM. Si tu utilisais 2 fois b[a] dans ta méthode, ça ne serait plus thread safe il y aurait un risque de modif de b[a] en cours de méthode, et donc un comportement non déterministe.
Bruno
-- Bruno Causse http://perso.wanadoo.fr/othello
pasde.hcyrano.spam
Bruno Causse wrote:
Fabien LE LEZ wrote:
Ici, une autre fonction peut modifier b[a] en même temps. je ne pensais pas a ca (b est const en realité)
mais si un deuxieme objet appele la methode pendant q'un autre l' utilise partagent t'ils le meme a et c?
A priori, comme cette fonction ne modifie rien, si std::string est thread-safe, la fonction l'est aussi, i.e. tu peux appeler plusieurs fois cette fonction avec le même paramètre en même temps. Toutefois, si l'objet passé en argument par référence est modifié en même temps par une autre fonction, ce n'est plus thread-safe.
On Mon, 26 Dec 2005 12:49:33 +0100, pasde.hcyrano.spam@free.fr (Bruno
Causse):
mais si un deuxieme objet appele la methode pendant q'un autre l'
utilise partagent t'ils le meme a et c?
Dans le code
int MaClass::maMethodeStatic(int a) {
int c = a - 4;
les objets a et c sont des variables automatiques locales, donc il n'y
a aucun partage avec une autre instance de la fonction.
A priori, comme cette fonction ne modifie rien, si std::string est
thread-safe, la fonction l'est aussi, i.e. tu peux appeler plusieurs
fois cette fonction avec le même paramètre en même temps.
Toutefois, si l'objet passé en argument par référence est modifié en
même temps par une autre fonction, ce n'est plus thread-safe.
A priori, comme cette fonction ne modifie rien, si std::string est thread-safe, la fonction l'est aussi, i.e. tu peux appeler plusieurs fois cette fonction avec le même paramètre en même temps. Toutefois, si l'objet passé en argument par référence est modifié en même temps par une autre fonction, ce n'est plus thread-safe.
pasde.hcyrano.spam
Fabien LE LEZ wrote:
les objets a et c sont des variables automatiques locales, donc il n'y a aucun partage avec une autre instance de la fonction.
donc si j'ai bien compris
les variables automatiques sont crées a chaque appel de la methode meme si un autre appel est en cour (autre thread).
une ref est aussi une variable auto donc deux objets COsMove (const) peuvent acceder en meme temps a la methode.
merci -- Bruno Causse http://perso.wanadoo.fr/othello
Fabien LE LEZ <gramster@gramster.com> wrote:
les objets a et c sont des variables automatiques locales, donc il n'y
a aucun partage avec une autre instance de la fonction.
donc si j'ai bien compris
les variables automatiques sont crées a chaque appel de la methode meme
si un autre appel est en cour (autre thread).
une ref est aussi une variable auto donc deux objets COsMove (const)
peuvent acceder en meme temps a la methode.
merci
--
Bruno Causse
http://perso.wanadoo.fr/othello
Prends donc le temps de formuler correctement tes idées, en français si possible.
désolé,
-- Bruno Causse http://perso.wanadoo.fr/othello
kanze
Bruno Causse wrote:
une methode de classe qui ne modifie que ses variables locales est elle thread safe?
par ex :
MaClass { static int b[100]; static int maMethodeStatic(int a); };
int MaClass::maMethodeStatic(int a) { int c = a - 4; return c*7+ b[a]; }
mon intuition me dit que c'est le bazar
Je ne comprends pas la question ? Qu'entends-tu par « thread safe » ici ?
Normallement, si une fonction a été conçue pour être utilisée dans un environement multi-thread, elle documente ce qu'il lui faut. Si elle est conforme à la documentation, elle est « thread safe ». Si elle n'est pas conforme, OU qu'il n'y a pas de documentation, elle ne l'est pas. Mais parler de la « thread safety » d'une fonction en isolation, sans citer les garanties documentées qu'elle donne, n'a pas de sens. La « thread safety » ne se traite pas au niveau des fonctions isolées, mais à un niveau plus haut ; tout ce qu'on peut démander à une fonction isolée, c'est qu'elle respecte sa documentation.
-- 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 wrote:
une methode de classe qui ne modifie que ses variables locales
est elle thread safe?
par ex :
MaClass {
static int b[100];
static int maMethodeStatic(int a);
};
int MaClass::maMethodeStatic(int a) {
int c = a - 4;
return c*7+ b[a];
}
mon intuition me dit que c'est le bazar
Je ne comprends pas la question ? Qu'entends-tu par « thread
safe » ici ?
Normallement, si une fonction a été conçue pour être utilisée
dans un environement multi-thread, elle documente ce qu'il lui
faut. Si elle est conforme à la documentation, elle est « thread
safe ». Si elle n'est pas conforme, OU qu'il n'y a pas de
documentation, elle ne l'est pas. Mais parler de la « thread
safety » d'une fonction en isolation, sans citer les garanties
documentées qu'elle donne, n'a pas de sens. La « thread safety »
ne se traite pas au niveau des fonctions isolées, mais à un
niveau plus haut ; tout ce qu'on peut démander à une fonction
isolée, c'est qu'elle respecte sa documentation.
--
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
une methode de classe qui ne modifie que ses variables locales est elle thread safe?
par ex :
MaClass { static int b[100]; static int maMethodeStatic(int a); };
int MaClass::maMethodeStatic(int a) { int c = a - 4; return c*7+ b[a]; }
mon intuition me dit que c'est le bazar
Je ne comprends pas la question ? Qu'entends-tu par « thread safe » ici ?
Normallement, si une fonction a été conçue pour être utilisée dans un environement multi-thread, elle documente ce qu'il lui faut. Si elle est conforme à la documentation, elle est « thread safe ». Si elle n'est pas conforme, OU qu'il n'y a pas de documentation, elle ne l'est pas. Mais parler de la « thread safety » d'une fonction en isolation, sans citer les garanties documentées qu'elle donne, n'a pas de sens. La « thread safety » ne se traite pas au niveau des fonctions isolées, mais à un niveau plus haut ; tout ce qu'on peut démander à une fonction isolée, c'est qu'elle respecte sa documentation.
-- 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
kanze
Bruno Jouhier wrote:
"Bruno Causse" a écrit dans le message de news: 1h86gmc.y5hu8u3ops3cN%
Fabien LE LEZ wrote:
Ici, une autre fonction peut modifier b[a] en même temps. je ne pensais pas a ca (b est const en realité)
mais si un deuxieme objet appele la methode pendant q'un autre l' utilise partagent t'ils le meme a et c?
Non. Chaque thread a sa propre pile pour les variables locales et le passage de paramètres. Pas de risque d'interférences ici.
Si b est const, ce code est parfaitement sûr.
Si b ne l'est pas, ça reste en fait thread safe car tu as un seul accès à b[a] dans ta méthode et car les types manipulés (référence sur le tableau et int) sont gérés de manière atomique par la VM.
Est-ce que tu pourrais t'expliquais ? À commencer par ce que tu entends par la VM.
En tout cas, la norme Posix dit que c'est un comportement indéfini si un thread modifie un objet, et qu'on l'accède depuis un autre thread, quelque soit le type d'accès dans l'autre thread.
Si tu utilisais 2 fois b[a] dans ta méthode, ça ne serait plus thread safe il y aurait un risque de modif de b[a] en cours de méthode, et donc un comportement non déterministe.
Tout dépend de la plateforme, naturellement, mais selon Posix, dès qu'un objet sert dans plus d'un thread, et qu'au moins un thread le modifie, il faut que tous les accès, dans tous les threads, soient synchronisés. Autant que je sache, Windows ne garantit pas plus.
Note aussi que l'atomicité n'est qu'un des problèmes potentiels. (Et que l'atomicité de l'accès à un int n'est pas garantie sur certaines architectures, comme Intel 32 bits.)
-- 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 Jouhier wrote:
"Bruno Causse" <pasde.hcyrano.spam@free.fr> a écrit dans le
message de news:
1h86gmc.y5hu8u3ops3cN%pasde.hcyrano.spam@free.fr...
Fabien LE LEZ <gramster@gramster.com> wrote:
Ici, une autre fonction peut modifier b[a] en même temps.
je ne pensais pas a ca (b est const en realité)
mais si un deuxieme objet appele la methode pendant q'un
autre l' utilise partagent t'ils le meme a et c?
Non. Chaque thread a sa propre pile pour les variables locales
et le passage de paramètres. Pas de risque d'interférences
ici.
Si b est const, ce code est parfaitement sûr.
Si b ne l'est pas, ça reste en fait thread safe car tu as un
seul accès à b[a] dans ta méthode et car les types manipulés
(référence sur le tableau et int) sont gérés de manière
atomique par la VM.
Est-ce que tu pourrais t'expliquais ? À commencer par ce que tu
entends par la VM.
En tout cas, la norme Posix dit que c'est un comportement
indéfini si un thread modifie un objet, et qu'on l'accède depuis
un autre thread, quelque soit le type d'accès dans l'autre
thread.
Si tu utilisais 2 fois b[a] dans ta méthode, ça ne serait plus
thread safe il y aurait un risque de modif de b[a] en cours de
méthode, et donc un comportement non déterministe.
Tout dépend de la plateforme, naturellement, mais selon Posix,
dès qu'un objet sert dans plus d'un thread, et qu'au moins un
thread le modifie, il faut que tous les accès, dans tous les
threads, soient synchronisés. Autant que je sache, Windows ne
garantit pas plus.
Note aussi que l'atomicité n'est qu'un des problèmes potentiels.
(Et que l'atomicité de l'accès à un int n'est pas garantie sur
certaines architectures, comme Intel 32 bits.)
--
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" a écrit dans le message de news: 1h86gmc.y5hu8u3ops3cN%
Fabien LE LEZ wrote:
Ici, une autre fonction peut modifier b[a] en même temps. je ne pensais pas a ca (b est const en realité)
mais si un deuxieme objet appele la methode pendant q'un autre l' utilise partagent t'ils le meme a et c?
Non. Chaque thread a sa propre pile pour les variables locales et le passage de paramètres. Pas de risque d'interférences ici.
Si b est const, ce code est parfaitement sûr.
Si b ne l'est pas, ça reste en fait thread safe car tu as un seul accès à b[a] dans ta méthode et car les types manipulés (référence sur le tableau et int) sont gérés de manière atomique par la VM.
Est-ce que tu pourrais t'expliquais ? À commencer par ce que tu entends par la VM.
En tout cas, la norme Posix dit que c'est un comportement indéfini si un thread modifie un objet, et qu'on l'accède depuis un autre thread, quelque soit le type d'accès dans l'autre thread.
Si tu utilisais 2 fois b[a] dans ta méthode, ça ne serait plus thread safe il y aurait un risque de modif de b[a] en cours de méthode, et donc un comportement non déterministe.
Tout dépend de la plateforme, naturellement, mais selon Posix, dès qu'un objet sert dans plus d'un thread, et qu'au moins un thread le modifie, il faut que tous les accès, dans tous les threads, soient synchronisés. Autant que je sache, Windows ne garantit pas plus.
Note aussi que l'atomicité n'est qu'un des problèmes potentiels. (Et que l'atomicité de l'accès à un int n'est pas garantie sur certaines architectures, comme Intel 32 bits.)
-- 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
