Prévenir une application à partir d'une DLL

Version imprimable

31/10/2007, 12h45
Tuizi

Prévenir une application à partir d'une DLL

Bonjour,

Voila j'ai une DLL qui va écrire des informations dans un de la mémoire partagé, et je voudrais quel informe mon application d'aller lire celle-ci.
En faite je chercher à créer une sorte d'évenement qu'une DLL envoie à mon programme.
ATTENTION: ma DLL et mon programme ne sont pas dans le meme processus.

J'ai regardé du coté des mutex, semaphore, mais j'arrive pas à trouver le mécanisme le plus optimisé pour cela.

Je fais donc appel à votre expérience :)

Merci d'avance.
31/10/2007, 14h38
Médinoc

Pour ça, je conseillerais un Manual-Reset Event, sans doute nommé.
Plus un mutex (ou plus compliqué si tu veux supporter plus d'un lecteur simultané) pour éviter que la DLL écrive dans la mémoire au moment où l'autre processus lit.
Je pense que l'événement devrait être resetté par la DLL dès qu'elle récupère le mutex pour écrire, et signalé à la fin (avant ou après la libération du mutex par la DLL).
31/10/2007, 14h38
ram-0000

Un événement nommé créé par ta DLL, positionné par ta DLL,
testé par ton programme, effacé par ton programme

Voir la fonction CreateEvent() et ses soeurs (http://msdn2.microsoft.com/en-us/library/ms682396.aspx)

En fait, cela peut aussi être un fichier créé par ta DLL et testé/effacé par ton programme

Quand tu dis "Voila j'ai une DLL qui va écrire des informations dans un de la mémoire partagé, et je voudrais quel informe mon application d'aller lire celle-ci.", en fait tu veux dire "J'ai un programme qui utilise une DLL qui va écrire ..." ?

Est ce que ce programme est actif en permanence car si ce programme s'arrête, son arrêt risque d'effacer les objets qu'il aura créé (Event, mutex, semaphore, ...) et il faut donc se tourner vers un moyen persistant

J'espère que je me fais comprendre
31/10/2007, 16h23
Tuizi

En faite le programme qui utilise ma DLL sera forcément couper avant mon programme.

Je vais regarder du coté du CreateEvent() car en faite je voudrais que mon programme reçoivent un evenement qui lui dit qu'il peut aller lire dans la mémoire partagé, au lieu de bouclé jusqu'a détecter un changement dans la mémoire.

Médinoc> je ne connais Manual-Reset Event je vais regarder cela aussi.

Merci pour vos réponses, je vais tester tous ça et je vous tiens au courant si j'ai des questions ou autres
31/10/2007, 16h31
ram-0000

Alors je pense que le CreateEvent n'est pas bon (pour info, l'idée "Manual-Reset Event" de Médinoc, c'est la même chose que mon idée "CreateEvent", c'est juste la manière de le dire qui n'est pas identique)

C'est pas bon, porquoi ?
Car ton 1er programme va créer un Event nommé (par CreateEvent), va le signaler et ensuite va s'arrêter.
Comme le programme s'arrête, l'Event nommé n'a plus de propriétaire, donc le système va le détruire automatiquement (et tu ne peux rien faire contre)

Toute solution à base d'objet Microsoft nommé (Event, MailSlot, Pipe, Shared memory, ...) aura le même comportement. Je pense que tu vas être obligé de te rabattre sur la solution à base de fichier

Le 1er programme crée un fichier quelconque et s'arrête. Le second programme teste la présence de ce fichier, réagit en conséquence et déventuellementy détruit le fichier. C'est le seul moyen que je voie pour créer une notion de persistance.
31/10/2007, 17h14
Tuizi

Il n'y a pas un moyen simple pour faire:

Mon programme (A) lance un programme (B) qui va charger ma DLL
Une fonction de ma DLL va être appelé, j'envois donc un événement à mon programme A.
Mon programme B qui execute ma DLL , s'arrete, la DLL est déchargé. Pas de problème mon programme A ne va pu recevoir d'évênement et c'est tant mieux.

En aucun cas le programme A va s'arreter avant le programme B

Voila en gros le fonctionnement.
Donc le principe de l'évênement me plait bien moi.
31/10/2007, 17h52
ram-0000

Citation:

Envoyé par Tuizi

Mon programme (A) lance un programme (B) qui va charger ma DLL
Une fonction de ma DLL va être appelé, j'envois donc un événement à mon programme A.
Mon programme B qui execute ma DLL , s'arrete, la DLL est déchargé. Pas de problème mon programme A ne va pu recevoir d'évênement et c'est tant mieux.

En aucun cas le programme A va s'arreter avant le programme B

Alors, si c'est ce fonctionnement, cela va marcher à condition que:
1/ L'événement nommé doit être créé par le programme (A)
2/ L'événement nommé est eventuellement positionné par la DLL appelée par le programme (B) lui même lancé par le programme (A)
3/ L'événement est testé ensuite par le programme (A)
4/ l'événement est effacé (explicitement ou implicitement) à l'arrêt du programme (A)

Dans tous les cas, il faut que l'événement soit créé par (A). Sinon, si il est créé par la DLL appellée par (B), il sera effacé du système automatiquement lors de l'arrêt de (B)
Ce mécanisme impose à (A) et à la DLL de connaitre le même nom de l'objet "Event nommé".
01/11/2007, 13h17
Tuizi

ok merci, je vais tacher de suivre cette démarche :P
07/11/2007, 11h54
Tuizi

Petite question pour le CreateEvent, quel est la différence entre le reset manuel et celui automatique?

La méthode automatique est mieux nan? enfin plus pratique?

Merci
07/11/2007, 16h03
ram-0000

Je suppose effectivement que dans ton cas, un événement avec reset automatique est plus indiqué.

Toutefois, dans d'autres contextes, un reset manuel est plus indiqué (je n'ai pas d'exemple immédiat en tête)
07/11/2007, 16h10
Médinoc

Raymond Chen n'est pas d'accord avec vous.
En clair, les Auto-Reset Events sont rarement appropriés: La plupart du temps, il vaut mieux utiliser un Event manuel (au moins, on sait ce qu'on fait avec celui-là) ou un sémaphore.

Je ne suis pas d'accord

Si plusieurs threads sont en attente sur un event, le comportement est différent si il y a manuel reset ou automatique reset.

Dans le cas d'un manual reset, tous les threads en attente sur l'event sont libérés, dans le cas d'un automatique reset, un seul thread est libéré
un petit bout de code (attention, aucun controle n'est effectué, c'est du brut de décoffrage)

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
 
#include "stdafx.h"
#include <windows.h>
 
HANDLE hThread[2];
HANDLE hEvent;
 
BOOL ModeManualReset = FALSE;
 
DWORD WINAPI _start(LPVOID lpParameter)
{
	DWORD id = (DWORD)lpParameter;
	for(;;)
	{
		printf("Thread %d is waiting...\n", id);
		WaitForSingleObject(hEvent, INFINITE);
		ResetEvent(hEvent);
		printf("Thread %d is released\n", id);
	}
}
 
int _tmain(int /*argc*/, _TCHAR* /*argv*/[])
{
	// create the event
	printf("ManualReset=%s\n", ModeManualReset== TRUE ? "TRUE" : "FALSE");
	hEvent = CreateEvent(NULL, ModeManualReset, FALSE, NULL);
 
	// create 3 thread
	DWORD id;
	HANDLE h = CreateThread(NULL, 0, _start, (void *)5, 0, &id);
	hThread[0] = h;
 
	h = CreateThread(NULL, 0, _start, (void *)6, 0, &id);
	hThread[1] = h;
 
	printf("Main thread is sleeping...\n");
	Sleep(5000);
	printf("Main thread is signaling the event...\n");
	SetEvent(hEvent);
 
	printf("Main thread is waiting...\n");
	WaitForMultipleObjects(sizeof(hThread) / sizeof(hThread[0]), hThread, TRUE, INFINITE);
	printf("Main thread is released\n");
	return 0;
}

Le résultat quand ManuelReset = FALSE

Code:

1
2
3
4
5
6
7
8
9
 
ManualReset=FALSE
Main thread is sleeping...
Thread 5 is waiting...
Thread 6 is waiting...
Main thread is signaling the event...
Main thread is waiting...
Thread 5 is released
Thread 5 is waiting...

Le résultat quand ManuelReset = TRUE

Code:

1
2
3
4
5
6
7
8
9
10
11
 
ManualReset=TRUE
Main thread is sleeping...
Thread 6 is waiting...
Thread 5 is waiting...
Main thread is signaling the event...
Main thread is waiting...
Thread 5 is released
Thread 6 is released
Thread 6 is waiting...
Thread 5 is waiting...

Donc je persiste à croire que dans certains cas, le mode automatique est plus indiqué que le mode manuel

07/11/2007, 17h26
Médinoc

Mais ce que dit Raymond Chen, c'est justement "Quitte à utiliser un truc qui ne libère qu'un seul thread, autant utiliser un sémaphore", car un Auto-Reset Event, c'est un sémaphore en moins bien.