Discussion :

[NiamorH]

Je viens de me heurter à un deadlock avec ce programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
#include <Windows.h>

DWORD WINAPI EntryPoint( void * )
{
	MSG msg;
	while ( GetMessage( &msg, NULL, 0, 0 ) )
	{
	}

	return 0;
}

int WINAPI WinMain( HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPSTR lpCmdLine,
    int nCmdShow )
{
	DWORD id;
	HANDLE th = CreateThread( NULL, 0, EntryPoint, NULL, 0, &id );
		
	//Sleep( 1000 );

	PostThreadMessage( id, WM_QUIT, 0, 0 );
	
	WaitForSingleObject( th, INFINITE );
}

Le thread créé ne reçoit jamais mon message.
Il suffit que je décommente le Sleep pour que je reçoive toujours mon message.

Alors je me demande dans quelle mesure mon thread est créé s'il n'est pas cappable de recevoir mes messages... Rien n'est dit sur la msdn. Cela m'oblige à instaurer un mécanisme d'attente pour être sûr que mon thread est arrivé à la boucle des messages avant de lui en envoyer.

[ram-0000]

Dans Winmain, tu créé un event, tu créé ton thread et tu te met en attente bloquante (ou avec timeout) sur ton event.

Quand ton thread est parti, il signale ton event (cela doit être une variable globale à Winmain et à ton thread ou alors une variable du contexte du thred).

Winmain est libéré, il peut détruire l'event (plus utile) et poster le message au thread.

[NiamorH]

C'est ce que j'ai essayé mais visiblement, ça ne marche que 10 fois sur 11. J'arrive quand même à des deadlock avec ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
#include <Windows.h>

HANDLE hevent;

DWORD WINAPI EntryPoint( void * )
{

	SetEvent( hevent );

	MSG msg;
	while ( GetMessage( &msg, NULL, 0, 0 ) )
	{
	}

	return 0;
}

int WINAPI WinMain( HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPSTR lpCmdLine,
    int nCmdShow )
{
	hevent = CreateEvent( NULL, TRUE, FALSE, NULL );

	DWORD id;
	HANDLE th = CreateThread( NULL, 0, EntryPoint, NULL, 0, &id );
	
	WaitForSingleObject( hevent, INFINITE );

	PostThreadMessage( id, WM_QUIT, 0, 0 );
	
	WaitForSingleObject( th, INFINITE );
}

Etrange non ? Il semblerait que même une fois rentré dans EntryPoint, la file de message ne soit pas fiable.

[Médinoc]

Fais un PeekMessage() avec le flag PM_NOREMOVE au début de ton thread, AVANT le SetEvent().
Ainsi, tu seras sûr que la file de messages correspondant au thread a été créée (elle n'est créée que lors du premier appel à une fonction qui s'y rapporte).

PS: À ta place, j'utiliserais WaitForMultipleObjects() sur l'event et le thread, histoire de choper une fin anormale du thread (même si ce n'est pas censé arriver).

[NiamorH]

Très bonne idée le peekmessage

elle n'est créée que lors du premier appel à une fonction qui s'y rapporte

C'est documenté quelque part ? je n'ai pas trouvé dans la msdn.

Et oui, tu as raison pour le wait multiple.


En fait je suis en train de recoder un truc que j'avais fait il y a un peu plus d'un an maintenant, mais que j'ai bêtement perdu...

Et au fur et à mesure, les souvenirs me reviennent (de mauvais souvenirs) sur la fiabilité de PostThreadMessage.

Il me semble me rappeller que même une fois bien lancé, si on envoie au thread plusieurs messages à la volée consécutivement, il se peut qu'il en perdre quelques uns au passage...

Du coup j'avais réimplémenté ma propre file de message, basée sur un conteneur standard encapsulé par des sections critiques. Et la je recevait bien tous mes messages d'un thread à l'autre.

[Médinoc]

C'est documenté quelque part ? je n'ai pas trouvé dans la msdn.

Ahem! Doc de PostThreadMessage()

[NiamorH]

merde, j'ai pas vu !

En tout cas j'ai plus de soucis de deadlock avec l'ajout de la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE );

Merci!

[NiamorH]

Avec ce code, jusqu'à NBMESSAGES = 6000 tou va bien, mais au dessus les messages se perdent.

Bon j'aurais surement rarement l'occasion d'en envoyer autant comme ça dans une appli de toute manière...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
#include <Windows.h>

HANDLE hevent;
int nb = 0;
int NBMESSAGES = 7000;

DWORD WINAPI SenderThread( void * idMainThread )
{
	DWORD id = (DWORD)idMainThread;

	for ( int i = 0; i < NBMESSAGES; ++i )
		PostThreadMessage( id, WM_USER+100, 0, 0 );

	return 0;
}

DWORD WINAPI MainThread( void * )
{
	MSG msg;
	PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE );

	SetEvent( hevent );

	while ( GetMessage( &msg, NULL, 0, 0 ) )
	{
		if ( msg.message == WM_USER+100 )
			++nb;
	}

	return 0;
}

int WINAPI WinMain( HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPSTR lpCmdLine,
    int nCmdShow )
{
	hevent = CreateEvent( NULL, TRUE, FALSE, NULL );

	DWORD id, id1, id2;
	HANDLE th = CreateThread( NULL, 0, MainThread, NULL, 0, &id );
	
	WaitForSingleObject( hevent, INFINITE );

	HANDLE thrds[2];
	thrds[0] = CreateThread( NULL, 0, SenderThread, (LPVOID)id, 0, &id1 );
	thrds[1] = CreateThread( NULL, 0, SenderThread, (LPVOID)id, 0, &id2 );

	WaitForMultipleObjects( 2, thrds, TRUE, INFINITE );

	PostThreadMessage( id, WM_QUIT, 0, 0 );
	
	WaitForSingleObject( th, INFINITE );
}

[ram-0000]

Peut être que tu pourrait tester le code de retour de PostThreadMessage()

Return Value

If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError. GetLastError returns ERROR_INVALID_THREAD_ID if idThread is not a valid thread identifier, or if the thread specified by idThread does not have a message queue.

[NiamorH]

ouep je vais essayer voir ce que ça dit.

Je me disais aussi que l'event pouvais aussi très bien être remplacé par un booléen volatile dans ce cas.

[Médinoc]

Et faire une boucle d'attente active/semi-active? Beurk!

[NiamorH]

En fait je l'ai lu ici et je me disais que ça permettait de ne pas avoir à se soucier ensuite de la libération du handle de l'event.
http://msdn.microsoft.com/en-us/library/12a04hfd.aspx

Mais effectivement, après test, Sleep( 0 ) est très consommateur du processeur. Donc pas top.

Je n'ai pas cherché encore mais Sleep(0) est sencé rendre la main aux autres threads si besoin c'est ça ? Celà inclut-il les threads des autres process ?

Voila un deuxième exemple en C# qui me parait suspect aussi, avec la boucle sur isalive http://msdn.microsoft.com/en-us/libr...y4(VS.80).aspx

[<nico>]

Avec ce code, jusqu'à NBMESSAGES = 6000 tou va bien, mais au dessus les messages se perdent.

Bon j'aurais surement rarement l'occasion d'en envoyer autant comme ça dans une appli de toute manière...

]

Pour avoir fait des essais, je ne pense pas que 6000 soit une limite, c'est juste que vous envoyer plus de messges que le thread n'as le temps d'en traiter et donc à un moment on arrive à saturation, ce qui ne devrait jamais arriver dans une application réelle.

Il suffit de rajouter un sleep dans le thread envoyant les messages pour s'en rendre compte.