PostThreadMessage trop tot après CreateThread

Version imprimable

Je viens de me heurter à un deadlock avec ce programme :
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 #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.

02/11/2008, 19h41
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.

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:

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.

03/11/2008, 10h47
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).
03/11/2008, 13h33
NiamorH

Très bonne idée le peekmessage :)

Citation:

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.
03/11/2008, 13h46
Médinoc

Citation:

Envoyé par NiamorH

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

Ahem! Doc de PostThreadMessage()
03/11/2008, 14h11
NiamorH

:oops: merde, j'ai pas vu !

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

Code:

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

Merci!

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:

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 );
}

03/11/2008, 15h07
ram-0000

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

Citation:

Envoyé par la doc MSDN

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.
04/11/2008, 00h34
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.
04/11/2008, 07h07
Médinoc

Et faire une boucle d'attente active/semi-active? Beurk!
04/11/2008, 08h06
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
16/06/2011, 21h54
<nico>

Citation:

Envoyé par 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...

]

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.