Coût de création et destruction de thread

Version imprimable

Voir 40 message(s) de cette discussion en une page

30/05/2005, 11h40
camboui

Je suis toujours là, si si ;)
Mais il m'arrive de faire des pauses pendant le WE.
Me revoici donc. Et c'est avec grand intérêt que je viens de lire le "moldave" qui m'a squatté :D

Je vais faire donc des essais avec ce que vous avez proposé.

Mais j'ai un autre soucis assez important, c'est celui-ci:
http://www.developpez.net/forums/viewtopic.php?t=343711
Non résolu à ce jour malgré une tentative de "projection aléatoire" qui donne des résultats incohérents.

Merci!
30/05/2005, 12h37
Mac LAK

Citation:

Envoyé par camboui

Mais j'ai un autre soucis assez important, c'est celui-ci:
http://www.developpez.net/forums/viewtopic.php?t=343711
Non résolu à ce jour malgré une tentative de "projection aléatoire" qui donne des résultats incohérents.

J'avais déjà vu ce topic, mais je n'ai d'idées que pour réduire la consommation mémoire de tes vecteurs, pas pour accélérer le temps de calcul... Sorry...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
struct Bazard
&#123;
	long v;
	bool run;
	HANDLE glevent,event;
&#125;;

DWORD WINAPI ThreadProc&#40;LPVOID lpParameter&#41;
&#123;
	Bazard *pb=&#40;Bazard *&#41;lpParameter;
	while &#40;1&#41;
	&#123;
		WaitForSingleObject&#40;pb->glevent,INFINITE&#41;;
		if &#40;!pb->run&#41;
			break;

		pb->v++;

		SetEvent&#40;pb->event&#41;;
	&#125;;
	return 0;
&#125;



int main&#40;int argc, char* argv&#91;&#93;&#41;
&#123;
	const int numThreads=2;
	int i;

	//create an event used to start all threads
	HANDLE glevent=CreateEvent&#40;NULL,FALSE,FALSE,NULL&#41;;
	//create an event for each thread
	HANDLE events&#91;numThreads&#93;;
	for&#40;i=0;i<numThreads;i++&#41;
		events&#91;i&#93;=CreateEvent&#40;NULL,FALSE,FALSE,NULL&#41;;

	//create each thread params
	Bazard b&#91;numThreads&#93;;
	for&#40;i=0;i<numThreads;i++&#41;
	&#123;
		b&#91;i&#93;.run=true;
		b&#91;i&#93;.glevent=glevent;
		b&#91;i&#93;.event=events&#91;i&#93;;
	&#125;

	//create threads
	DWORD hId&#91;numThreads&#93;;
	HANDLE ht&#91;numThreads&#93;;
	for&#40;i=0;i<numThreads;i++&#41;
		ht&#91;i&#93;=CreateThread&#40;NULL,120*1024,ThreadProc,&b,0,&hId&#91;i&#93;&#41;;

	//run and control threads
	for&#40;i=0;i<numThreads;i++&#41;
		b&#91;i&#93;.v=10*&#40;i+1&#41;;
	int c=5;
	while&#40;c--&#41;
	&#123;
		//resume all threads
		SetEvent&#40;glevent&#41;;

		//wait all threads suspension
		WaitForMultipleObjects&#40;numThreads,events,TRUE,INFINITE&#41;;

		//analyse each thread work
		for&#40;i=0;i<numThreads;i++&#41;
			cout << "thread " << i << "&#58; v=" << b&#91;i&#93;.v << endl;
	&#125;

	//allow threads to terminate
	for&#40;i=0;i<numThreads;i++&#41;
		b&#91;i&#93;.run=false;
	SetEvent&#40;glevent&#41;;
	WaitForMultipleObjects&#40;numThreads,ht,TRUE,INFINITE&#41;;

	//close all handles
	for&#40;i=0;i<numThreads;i++&#41;
	&#123;
		CloseHandle&#40;ht&#91;i&#93;&#41;;
		CloseHandle&#40;events&#91;i&#93;&#41;;
	&#125;
	CloseHandle&#40;glevent&#41;;
	return 0;
&#125;

Bon, ceci ne marche pas. Le code n'atteint jamais "//analyse each thread work" (reste bloqué dans WaitForMultipleObjects() de la boucle).
Par contre, ça marche si numThreads=1.
Ou est l'erreur?
Merci

30/05/2005, 18h07
Mac LAK

Normal, tu résume tes threads un par un, mais tu attends juste en dessous le résultat de tous les threads... :wink:

Bienvenue dans le monde de l'interblocage !! :twisted:

Solution : dégage ton WFMO de la boucle de resume, sinon tu n'en sortira jamais.
30/05/2005, 18h11
camboui

Citation:

Envoyé par Mac LAK

Citation:

Envoyé par camboui

Mais j'ai un autre soucis assez important, c'est celui-ci:
http://www.developpez.net/forums/viewtopic.php?t=343711
Non résolu à ce jour malgré une tentative de "projection aléatoire" qui donne des résultats incohérents.

J'avais déjà vu ce topic, mais je n'ai d'idées que pour réduire la consommation mémoire de tes vecteurs, pas pour accélérer le temps de calcul... Sorry...

Faisons abstraction de la mémoire ou du temps. Seul l'aspet mathématique compte pour comprendre.
J'ai fait une recherche sur google avec "Random projection in dimensionality reduction".
Mais j'ai du mal à comprendre ce qu'il faut faire "exactement" (il me faudrait un exemple de contenu chiffré de la matrice de projection).
30/05/2005, 18h16
camboui

Citation:

Envoyé par Mac LAK

Normal, tu résume tes threads un par un, mais tu attends juste en dessous le résultat de tous les threads... :wink:

Ben non. Il me semble que je les "resume" tous à la fois avec le SetEvent(glevent). Le WFSO dans la fonction du thread réagit pour tous les threads en même temps, non?
30/05/2005, 18h22
camboui

Citation:

Envoyé par Mac LAK

Normal, tu résume tes threads un par un, mais tu attends juste en dessous le résultat de tous les threads... :wink:

Bienvenue dans le monde de l'interblocage !! :twisted:

Solution : dégage ton WFMO de la boucle de resume, sinon tu n'en sortira jamais.

Il me semble avoir fait le minimum possible pourtant.

Dans la boucle du thread principal, j'autorise tous les threads de démarrer (SetEvent()), puis j'attends qu'ils aient tous finis (WFMO()).

Dans la fonction thread, j'attend l'autorisation de démarrer (WFSO()) puis je signale quand j'ai fini (SetEvent()).

Je pense que le problème est plutôt dans les ResetEvent() implicites. Quand ont-t-ils lieu exactement?
30/05/2005, 18h40
Mac LAK

Citation:

Envoyé par camboui

Ben non. Il me semble que je les "resume" tous à la fois avec le SetEvent(glevent). Le WFSO dans la fonction du thread réagit pour tous les threads en même temps, non?

C'est pas gagné d'avance... Insère ceci après ton WFSO, dans tes threads :

Code:

printf("Thread resumed : %08X\n",GetCurrentThreadId());

Surpris ? ;-)
Effectivement, le problème vient (à la base) de l'auto-reset de ton évènement : écris ça, plutôt :

Code:

HANDLE glevent=CreateEvent(NULL,TRUE,FALSE,NULL);

Tu rajouteras ensuite :

Code:

ResetEvent(glevent);

après ton WFMO inclus dans le "while (c--)".
Ca devrait normalement bien mieux marcher.

Rien n'a marché.
Mais j'ai vu le bug. Il est dans la création du thread lors du passage du paramètre Bazard:

Code:

ht[i]=CreateThread(NULL,120*1024,ThreadProc,&b[i],0,&hId[i]);

au lieu de

Code:

ht[i]=CreateThread(NULL,120*1024,ThreadProc,&b,0,&hId[i]);

aahlala :roll: Bon...

Ce gros bug corrigé, j'ai remarqué qu'il fallait bloquer les threads après avoir signalé au thread principal qu'ils ont fini leur traitement.
Voici donc un code qui fonctionne comme il faut:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 struct Bazard { long v; bool run; HANDLE startevent,stopevent,threadevent; }; DWORD WINAPI ThreadProc(LPVOID lpParameter) { DWORD id=GetCurrentThreadId(); Bazard *pb=(Bazard *)lpParameter; while (1) { WaitForSingleObject(pb->startevent,INFINITE); if (!pb->run) break; pb->v++; SetEvent(pb->threadevent); WaitForSingleObject(pb->stopevent,INFINITE); }; return 0; } int main(int argc, char* argv[]) { const int numThreads=4; int i; //create an manual-event used to start and stop all threads HANDLE startevent=CreateEvent(NULL,TRUE,FALSE,NULL); HANDLE stopevent=CreateEvent(NULL,TRUE,FALSE,NULL); //create an auto-reset event for each thread HANDLE threadevent[numThreads]; for(i=0;i<numThreads;i++) threadevent[i]=CreateEvent(NULL,FALSE,FALSE,NULL); //create each thread params Bazard b[numThreads]; for(i=0;i<numThreads;i++) { b[i].run=true; b[i].startevent=startevent; b[i].stopevent=stopevent; b[i].threadevent=threadevent[i]; } //create threads DWORD hId[numThreads]; HANDLE ht[numThreads]; for(i=0;i<numThreads;i++) ht[i]=CreateThread(NULL,120*1024,ThreadProc,&b[i],0,&hId[i]); //run and control threads for(i=0;i<numThreads;i++) b[i].v=10*(i+1); int c=5; while(c--) { //resume all threads ResetEvent(stopevent); SetEvent(startevent); //wait all thread events WaitForMultipleObjects(numThreads,threadevent,TRUE,INFINITE); ResetEvent(startevent); SetEvent(stopevent); //analyse each thread work for(i=0;i<numThreads;i++) cout << "thread " << i << ": v=" << b[i].v << endl; } //allow threads to terminate for(i=0;i<numThreads;i++) b[i].run=false; SetEvent(startevent); WaitForMultipleObjects(numThreads,ht,TRUE,INFINITE); //close all handles for(i=0;i<numThreads;i++) { CloseHandle(ht[i]); CloseHandle(threadevent[i]); } CloseHandle(startevent); CloseHandle(stopevent); return 0; }
Ça marche et je ne vois pas plus simple:
-un event global pour démarrer tous les threads;
-un event global pour arrêter tous les threads afin de les empêcher de boucler trop vite;
-un event par thread pour signaler au thread principal la fin du traitement.

Si tout le monde est d'accord et qu'il n'y a pas plus simple, je marquerai "résolu" :)

31/05/2005, 14h04
Mac LAK

A propos, mis à part si tu en as réellement besoin, il n'est pas nécessaire de spécifier la taille de la pile (2nd paramètre de CreateThread) lors de la création... Mettre "0" suffit amplement la plupart du temps, et ça simplifie pas mal les choses.

Citation:

Envoyé par camboui

Ça marche et je ne vois pas plus simple:
-un event global pour démarrer tous les threads;
-un event global pour arrêter tous les threads afin de les empêcher de boucler trop vite;
-un event par thread pour signaler au thread principal la fin du traitement.

Y'a plus simple... Y'a toujours plus simple... ;-)
Je te propose :
- Un event global à reset manuel : bloquer les threads sur cet évènement reseté à l'initialisation (avec un timeout INFINITE). Signaler l'évènement pour démarrer les threads.
- Pour arrêter les threads, reseter l'évènement depuis le thread principal.
- Un event par thread pour la signalisation de la fin de traitement, s'il est nécessaire de les identifier "individuellement". Si seul l'information "tous se sont terminés" est importante, utiliser plutôt un sémaphore (CreateSemaphore).

Bon, en tout cas, ça avance bien, c'est agréable.
31/05/2005, 14h29
camboui

Citation:

Envoyé par Mac LAK

A propos, mis à part si tu en as réellement besoin, il n'est pas nécessaire de spécifier la taille de la pile (2nd paramètre de CreateThread) lors de la création... Mettre "0" suffit amplement la plupart du temps, et ça simplifie pas mal les choses.

Citation:

Envoyé par camboui

Ça marche et je ne vois pas plus simple:
-un event global pour démarrer tous les threads;
-un event global pour arrêter tous les threads afin de les empêcher de boucler trop vite;
-un event par thread pour signaler au thread principal la fin du traitement.

Y'a plus simple... Y'a toujours plus simple... ;-)
Je te propose :
- Un event global à reset manuel : bloquer les threads sur cet évènement reseté à l'initialisation (avec un timeout INFINITE). Signaler l'évènement pour démarrer les threads.

Jusque là, ça va.

Citation:

Envoyé par Mac LAK

- Pour arrêter les threads, reseter l'évènement depuis le thread principal.

C'est là que ça coince. Je ne peux reseter que lorsque j'ai la main, c'est-à-dire lorsque TOUS les threads ont signalés leur event, ça ne les bloque donc pas juste après le SetEvent().

Citation:

Envoyé par Mac LAK

- Un event par thread pour la signalisation de la fin de traitement, s'il est nécessaire de les identifier "individuellement". Si seul l'information "tous se sont terminés" est importante, utiliser plutôt un sémaphore (CreateSemaphore).

En effet, j'ai juste besoin de savoir s'ils ont terminé. Je vais donc jeter un oeil aux semaphores.

Citation:

Envoyé par Mac LAK

Bon, en tout cas, ça avance bien, c'est agréable.

Merci à la communauté, à toi en particulier ;)
31/05/2005, 17h40
camboui

Et ce qui devait arriver, arriva... :(

J'ai donc implémenté le code donc question plus haut dans un cas bien concret. Ça marche pendant quelques (dizaines) itérations, puis blocage.
Jamais à la même itération, bien sûr :evil:

Comment debugger, comment savoir où est le blocage?
31/05/2005, 17h49
Mac LAK

Pour le reset/set manuel, n'oublie pas que tu peux "tester" l'état d'un event sans bloquer, en mettant WFSO(hEvent,0)... ;-)

Citation:

Envoyé par camboui

Comment debugger, comment savoir où est le blocage?

Oh, les joies du debug multithread ! :twisted:
Déjà, avec quel compilateur/IDE travailles-tu ? Ca m'aidera pour t'indiquer la meilleure démarche... Tous les IDE ne sont pas égaux devant le debug...
01/06/2005, 09h59
camboui

:(

MS VC++ 6

Ceci semble ne plus bloquer:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
struct Bazard
&#123;
	long v;
	bool run;
	HANDLE startevent,stopevent,threadevent;
&#125;;

DWORD WINAPI ThreadProc&#40;LPVOID lpParameter&#41;
&#123;
	Bazard *pb=&#40;Bazard *&#41;lpParameter;
	while &#40;1&#41;
	&#123;
		WaitForSingleObject&#40;pb->startevent,INFINITE&#41;;

		if &#40;!pb->run&#41;
			break;

		pb->v++;

		SetEvent&#40;pb->threadevent&#41;;
		WaitForSingleObject&#40;pb->stopevent,INFINITE&#41;;
	&#125;;
	return 0;
&#125;


int main&#40;int argc, char* argv&#91;&#93;&#41;
&#123;
	const int numThreads=4;
	int i;

	//create manual-events used to start and stop all threads
	HANDLE startevent=CreateEvent&#40;NULL,TRUE,FALSE,NULL&#41;;
	HANDLE stopevent=CreateEvent&#40;NULL,TRUE,FALSE,NULL&#41;;
	//create an auto-reset event for each thread
	HANDLE threadevent&#91;numThreads&#93;;
	for&#40;i=0;i<numThreads;i++&#41;
		threadevent&#91;i&#93;=CreateEvent&#40;NULL,FALSE,FALSE,NULL&#41;;

	//create each thread params
	Bazard b&#91;numThreads&#93;;
	for&#40;i=0;i<numThreads;i++&#41;
	&#123;
		b&#91;i&#93;.run=true;
		b&#91;i&#93;.startevent=startevent;
		b&#91;i&#93;.stopevent=stopevent;
		b&#91;i&#93;.threadevent=threadevent&#91;i&#93;;
	&#125;

	//create threads
	DWORD hId&#91;numThreads&#93;;
	HANDLE ht&#91;numThreads&#93;;
	for&#40;i=0;i<numThreads;i++&#41;
		ht&#91;i&#93;=CreateThread&#40;NULL,120*1024,ThreadProc,&b&#91;i&#93;,0,&hId&#91;i&#93;&#41;;

	//run and control threads
	for&#40;i=0;i<numThreads;i++&#41;
		b&#91;i&#93;.v=10*&#40;i+1&#41;;
	int c=5;
	while&#40;c--&#41;
	&#123;
		//resume all threads
		ResetEvent&#40;stopevent&#41;;
		SetEvent&#40;startevent&#41;;

		//wait all thread events
		WaitForMultipleObjects&#40;numThreads,threadevent,TRUE,INFINITE&#41;;
		ResetEvent&#40;startevent&#41;;
		Sleep&#40;0&#41;;
		SetEvent&#40;stopevent&#41;;

		//analyse each thread work
		for&#40;i=0;i<numThreads;i++&#41;
			cout << "thread " << i << "&#58; v=" << b&#91;i&#93;.v << endl;
	&#125;

	//allow threads to terminate
	for&#40;i=0;i<numThreads;i++&#41;
		b&#91;i&#93;.run=false;
	SetEvent&#40;startevent&#41;;
	WaitForMultipleObjects&#40;numThreads,ht,TRUE,INFINITE&#41;;

	//close all handles
	for&#40;i=0;i<numThreads;i++&#41;
	&#123;
		CloseHandle&#40;ht&#91;i&#93;&#41;;
		CloseHandle&#40;threadevent&#91;i&#93;&#41;;
	&#125;
	CloseHandle&#40;startevent&#41;;
	CloseHandle&#40;stopevent&#41;;
	return 0;
&#125;

Unique changement, le Sleep(0) après le WMFO.

Le blocage survient, je suppose, entre le SetEvent() et le WFSO(stopevent) dans la fonction thread, le thread principal étant déjà revenu sur le ResetEvent(stopevent).

01/06/2005, 11h35
Mac LAK

Avec VC++, tu peux choisir quel thread tu veux analyser, lors du debug.
Tu as également accès à l'examen de quasiment n'importe quoi, et au call stack si nécessaire.

Un appel à Sleep(0) ne fait rien, hormis provoquer une commutation de threads.
Pour "voir" où se bloque ton système, il te faudra utiliser par exemple la fonction OutputDebugString, ou un appel à TRACE, en posant les infos de debug suivantes :
- Pour chaque affichage, insérer le ThreadID du thread appelant (histoire de savoir quel est le thread qui a bien pu émettre le message...).
- Mettre un OutputDebugString avant et après les fonctions suivantes : CreateThread, CreateEvent, SetEvent, ResetEvent et WaitForSingleObject. A chaque fois, afficher les informations pertinentes : handle de l'évènement, ThreadID, résultat du WFSO, etc...
- Mettre un OutputDebugString dans les clauses de sortie des boucles, et sur la condition de continuation de ces boucles si besoin est. En rajouter un, par exemple, entre le test de "pb->run" et le "break".

Lance ton programme, observe la console de debug : la raison du blocage devrait être bien plus claire.
01/06/2005, 14h37
camboui

Citation:

Envoyé par Mac LAK

Avec VC++, tu peux choisir quel thread tu veux analyser, lors du debug.
Tu as également accès à l'examen de quasiment n'importe quoi, et au call stack si nécessaire.

OK, merci :D
Le passage d'un thread à un autre pour la consultation de son état n'est pas très pratique avec VC++6, mais ça fonctionne et on voit "beaucoup de choses".

Citation:

Envoyé par Mac LAK

Un appel à Sleep(0) ne fait rien, hormis provoquer une commutation de threads.

C'était justement le but ;)

Citation:

Envoyé par Mac LAK

Pour "voir" où se bloque ton système, il te faudra utiliser par exemple la fonction OutputDebugString, ou un appel à TRACE, en posant les infos de debug suivantes :
- Pour chaque affichage, insérer le ThreadID du thread appelant (histoire de savoir quel est le thread qui a bien pu émettre le message...).
- Mettre un OutputDebugString avant et après les fonctions suivantes : CreateThread, CreateEvent, SetEvent, ResetEvent et WaitForSingleObject. A chaque fois, afficher les informations pertinentes : handle de l'évènement, ThreadID, résultat du WFSO, etc...
- Mettre un OutputDebugString dans les clauses de sortie des boucles, et sur la condition de continuation de ces boucles si besoin est. En rajouter un, par exemple, entre le test de "pb->run" et le "break".

Lance ton programme, observe la console de debug : la raison du blocage devrait être bien plus claire.

Après quelques ODS ça et là, j'ai vite abandonné: je croule sous les messages.
Mais le break-execution au moment du dead-lock et la consultation des threads me permet de constater que c'est bien le ResetEvent(stopevent) qui a lieu "trop vite" dans le thread principal. Au moins un thread est resté coincé dans le WFSO(stopevent) alors qu'il devrait être dans le WFSO(startevent). Le Sleep(0) permet de "secouer" les threads, mais ce n'est pas très élégant.

Passons au semaphore: je ne comprend pas comment l'utiliser :(

Si j'ai bien compris, le WFSO n'attend que si la valeur du sémaphore est =0. Ca me parait idiot, c'est le contraire qu'il faudrait.
Ensuite, le ReleaseSemaphore permet d'incrémenter le semaphore. Et comment on remet sa valeur à 0?

Suite à d'autres discussions où l'on me conseille d'utiliser des event indépendants pour chaque thread en laissant tomber les event globaux, voici un code qui semble simple et fonctionnel:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
struct Bazard
&#123;
	long v;
	bool run;
	HANDLE startevent,threadevent;
&#125;;

DWORD WINAPI ThreadProc&#40;LPVOID lpParameter&#41;
&#123;
	Bazard *pb=&#40;Bazard *&#41;lpParameter;
	while &#40;1&#41;
	&#123;
		WaitForSingleObject&#40;pb->startevent,INFINITE&#41;;

		if &#40;!pb->run&#41;
			break;

		pb->v++;

		SetEvent&#40;pb->threadevent&#41;;
	&#125;;
	return 0;
&#125;



int main&#40;int argc, char* argv&#91;&#93;&#41;
&#123;
	const int numThreads=4;
	int i;

	HANDLE startevent&#91;numThreads&#93;,threadevent&#91;numThreads&#93;;
	for&#40;i=0;i<numThreads;i++&#41;
	&#123;
		//create auto-reset start/stop events for each thread
		startevent&#91;i&#93;=CreateEvent&#40;NULL,FALSE,FALSE,NULL&#41;;
		//create auto-reset events for each thread
		threadevent&#91;i&#93;=CreateEvent&#40;NULL,FALSE,FALSE,NULL&#41;;
	&#125;

	//create each thread params
	Bazard b&#91;numThreads&#93;;
	for&#40;i=0;i<numThreads;i++&#41;
	&#123;
		b&#91;i&#93;.run=true;
		b&#91;i&#93;.startevent=startevent&#91;i&#93;;
		b&#91;i&#93;.threadevent=threadevent&#91;i&#93;;
	&#125;

	//create threads
	DWORD hId&#91;numThreads&#93;;
	HANDLE ht&#91;numThreads&#93;;
	for&#40;i=0;i<numThreads;i++&#41;
		ht&#91;i&#93;=CreateThread&#40;NULL,0,ThreadProc,&b&#91;i&#93;,0,&hId&#91;i&#93;&#41;;

	//run and control threads
	for&#40;i=0;i<numThreads;i++&#41;
		b&#91;i&#93;.v=10*&#40;i+1&#41;;
	int c=5;
	while&#40;c--&#41;
	&#123;
		//resume each thread
		for&#40;i=0;i<numThreads;i++&#41;
			SetEvent&#40;startevent&#91;i&#93;&#41;;

		//wait all thread events
		WaitForMultipleObjects&#40;numThreads,threadevent,TRUE,INFINITE&#41;;

		//analyse each thread work
		for&#40;i=0;i<numThreads;i++&#41;
			cout << "thread " << i << "&#58; v=" << b&#91;i&#93;.v << endl;
	&#125;

	//allow threads to terminate
	for&#40;i=0;i<numThreads;i++&#41;
	&#123;
		b&#91;i&#93;.run=false;
		SetEvent&#40;startevent&#91;i&#93;&#41;;
	&#125;
	WaitForMultipleObjects&#40;numThreads,ht,TRUE,INFINITE&#41;;

	//close all handles
	for&#40;i=0;i<numThreads;i++&#41;
	&#123;
		CloseHandle&#40;ht&#91;i&#93;&#41;;
		CloseHandle&#40;threadevent&#91;i&#93;&#41;;
		CloseHandle&#40;startevent&#91;i&#93;&#41;;
	&#125;
	return 0;
&#125;

01/06/2005, 16h25
camboui

Citation:

Envoyé par camboui

Passons au semaphore: je ne comprend pas comment l'utiliser :(

Si j'ai bien compris, le WFSO n'attend que si la valeur du sémaphore est =0. Ca me parait idiot, c'est le contraire qu'il faudrait.
Ensuite, le ReleaseSemaphore permet d'incrémenter le semaphore. Et comment on remet sa valeur à 0?

OK, j'ai compris.
Mais je ne pense pas que se soit utile pour mon problème.
C'est plutôt pour gérer des files d'attentes ou des "entonoirs".
01/06/2005, 18h01
Mac LAK

Citation:

Envoyé par camboui

OK, j'ai compris.
Mais je ne pense pas que se soit utile pour mon problème.
C'est plutôt pour gérer des files d'attentes ou des "entonoirs".

C'est cool, tu fais les questions et les réponses tout seul, maintenant... :mrgreen:
Plus sérieusement, çà sert à "dénombrer" quelque chose : dans ton cas, chaque thread "terminé" décrémente le sémaphore, puis l'attend : ainsi, tes threads "franchiront" tous le WFSO(Semaphore) en même temps. Sauf, bien sûr, si tu rajoutes une unité à ton sémaphore, à l'usage du thread principal... :twisted:

Voir 40 message(s) de cette discussion en une page