Dans une applie Win32, je dois appeler une fonction search() qui peut
prendre une 30taine de secondes et qui contient une boucle infinie stoppée
par une variable globale. Si j'appelle cette fonction search() tel quel,
toute l'appli est gelée et ne répond plus. J'utilise alors :
DWORD thread1;
hThread1=CreateThread(
NULL, // pointer to thread security attributes
0, // initial thread stack size, in bytes
(unsigned long (__stdcall *)(void *))search,
NULL, // argument for new thread
0, // creation flags
&thread1 // pointer to returned thread identifier
);
Mais dans ce cas, il semble que la variable globale censée stopper la
recherche n'ait plus d'effet. Je suppose que le thread est un processus
parallèle et qui démarre avec une copie de cette variable globale. Comment
stopper la recherche avec cette variable globale ?
L'autre problème, qui doit être identique est que si je clique sur la croix
pour fermer la fenêtre pendant une recherche, l'appli quitte seulement quand
le thread est terminé.
TerminateThread is a dangerous function> Patrick Mézard
En effet, merci. Je vais relire tout ça et voir si ExitThread est mieux.
kanze
"amerio" wrote in message news:<0Nr4b.30395$...
|> -> Utilise "volatile"
Volatile n'apporte aucune garantie supplémentaire dans ce cas, au moins que la documentation du compilateur dit autrement. Il se peut, par exemple, que le code fonctionne avec volatile dans un contexte mono-processeur, mais non multi-processeur.
Oui, en fait, volatil garantit simplement que la variable ne sera pas lu depuis le cache, mais directement depuis la memoire.
Je ne sais pas d'où tu as ça. Ce n'est pas dans la norme.
La seule chose qu'il y a dans la norme, c'est que les « accès » à une variable volatile font partie du comportement visible du programme qu'un compilateur ne peut pas altérer. Si tu écris un accès à une variable volatile, donc, il doit y avoir un accès.
En revanche, la norme dit que ce que c'est qu'un accès est défini par l'implémentation. Toutes les implémentations que je connais, que ce soit sur Sparc ou sur I80x86, définit « accès » comme étant simplement l'exécution d'une instruction machine de lecture ou d'écriture. Accès dont à la cache locale du processeur, et encore, sans garantie d'ordre.
Mais en effet, ca n'interdit pas que deux autres threads puissent ecrire dedans en meme temps, et qu'on relise une valeur aberrante.
Ça n'interdit pas non plus qu'un thread y écrit, et que l'autre thread ne voit jamais la nouvelle valeur écrite.
Dans son cas précis, il precise pourtant qu'il n'y a que DEUX threads en tout : un qui ecrit, un qui lit. Donc meme en multiprocesseur, il n'aura pas de pb avec volatil (ou bien me trompe-je ?).
Tu te trompes.
Mais tu as raison de souligné le pb : la seule vrai solution serait un mutex, mais dans son cas, cela me parraissait un peu "lourd"...
C'est la seule que a un comportement défini.
De façon moins portable, certains systèmes pourraient fournir des fonctions qui marche avec une simple barrière de mémoire, sans passer par le noyau du système. Sur IA32, par exemple, si les « accès » se fait au moyen des instructions précédées par un LOCK préfixe, ça doit marcher.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"amerio" <amerio@hotmail.com> wrote in message
news:<0Nr4b.30395$2k4.309120@news.chello.at>...
|> -> Utilise "volatile"
Volatile n'apporte aucune garantie supplémentaire dans ce cas, au
moins que la documentation du compilateur dit autrement. Il se peut,
par exemple, que le code fonctionne avec volatile dans un contexte
mono-processeur, mais non multi-processeur.
Oui, en fait, volatil garantit simplement que la variable ne sera pas
lu depuis le cache, mais directement depuis la memoire.
Je ne sais pas d'où tu as ça. Ce n'est pas dans la norme.
La seule chose qu'il y a dans la norme, c'est que les « accès » à une
variable volatile font partie du comportement visible du programme qu'un
compilateur ne peut pas altérer. Si tu écris un accès à une variable
volatile, donc, il doit y avoir un accès.
En revanche, la norme dit que ce que c'est qu'un accès est défini par
l'implémentation. Toutes les implémentations que je connais, que ce soit
sur Sparc ou sur I80x86, définit « accès » comme étant simplement
l'exécution d'une instruction machine de lecture ou d'écriture. Accès
dont à la cache locale du processeur, et encore, sans garantie d'ordre.
Mais en effet, ca n'interdit pas que deux autres threads puissent
ecrire dedans en meme temps, et qu'on relise une valeur aberrante.
Ça n'interdit pas non plus qu'un thread y écrit, et que l'autre thread
ne voit jamais la nouvelle valeur écrite.
Dans son cas précis, il precise pourtant qu'il n'y a que DEUX threads
en tout : un qui ecrit, un qui lit. Donc meme en multiprocesseur, il
n'aura pas de pb avec volatil (ou bien me trompe-je ?).
Tu te trompes.
Mais tu as raison de souligné le pb : la seule vrai solution serait un
mutex, mais dans son cas, cela me parraissait un peu "lourd"...
C'est la seule que a un comportement défini.
De façon moins portable, certains systèmes pourraient fournir des
fonctions qui marche avec une simple barrière de mémoire, sans passer
par le noyau du système. Sur IA32, par exemple, si les « accès » se fait
au moyen des instructions précédées par un LOCK préfixe, ça doit
marcher.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Volatile n'apporte aucune garantie supplémentaire dans ce cas, au moins que la documentation du compilateur dit autrement. Il se peut, par exemple, que le code fonctionne avec volatile dans un contexte mono-processeur, mais non multi-processeur.
Oui, en fait, volatil garantit simplement que la variable ne sera pas lu depuis le cache, mais directement depuis la memoire.
Je ne sais pas d'où tu as ça. Ce n'est pas dans la norme.
La seule chose qu'il y a dans la norme, c'est que les « accès » à une variable volatile font partie du comportement visible du programme qu'un compilateur ne peut pas altérer. Si tu écris un accès à une variable volatile, donc, il doit y avoir un accès.
En revanche, la norme dit que ce que c'est qu'un accès est défini par l'implémentation. Toutes les implémentations que je connais, que ce soit sur Sparc ou sur I80x86, définit « accès » comme étant simplement l'exécution d'une instruction machine de lecture ou d'écriture. Accès dont à la cache locale du processeur, et encore, sans garantie d'ordre.
Mais en effet, ca n'interdit pas que deux autres threads puissent ecrire dedans en meme temps, et qu'on relise une valeur aberrante.
Ça n'interdit pas non plus qu'un thread y écrit, et que l'autre thread ne voit jamais la nouvelle valeur écrite.
Dans son cas précis, il precise pourtant qu'il n'y a que DEUX threads en tout : un qui ecrit, un qui lit. Donc meme en multiprocesseur, il n'aura pas de pb avec volatil (ou bien me trompe-je ?).
Tu te trompes.
Mais tu as raison de souligné le pb : la seule vrai solution serait un mutex, mais dans son cas, cela me parraissait un peu "lourd"...
C'est la seule que a un comportement défini.
De façon moins portable, certains systèmes pourraient fournir des fonctions qui marche avec une simple barrière de mémoire, sans passer par le noyau du système. Sur IA32, par exemple, si les « accès » se fait au moyen des instructions précédées par un LOCK préfixe, ça doit marcher.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
