Aide : DLL & Process_Detach & _beginthread

Bonjour,

J'ai un problème concernant la destruction de thread a l'intérieur d'un DLL. Voici la situation.
Il y a une DLL qui crée ses propres Thread (_beginthread). Lorsque l'application quitte, Process_Detach est appellé dans le DLLMain. A ce moment, je tente de tuer les Threads par suicide (c'est a dire, qu'un état est envoyé au Thread et que ce dernier interrompt son activité et se detruit).
Hors, il semble que lorsque Process_Detach est appellé, l'ensemble des Threads gèle et par conséquent, la mécanique de suicide ne fonctionne pas.

Savez vous pourquoi les Threads semblent gèler lors de la libération de la DLL ?

Merci beaucoup de votre aide.
sébastien

Bonjour,

Quote de Raymond Chen :

Citation:

---

This deadlock is much more commonly seen in DLL_PROCESS_DETACH, where a DLL wants to shut down its worker threads and wait for them to clean up before it unloads itself. You can't wait for a thread inside DLL_PROCESS_DETACH because that thread needs to send out the DLL_THREAD_DETACH notifications before it exits, which it can't do until your DLL_PROCESS_DETACH handler returns.

(It is for this thread cleanup case that the function FreeLibraryAndExitThread was created.)

---

Quote de la remarque de FreeLibraryAndExitThread :

Citation:

---

The FreeLibraryAndExitThread function allows threads that are executing within a DLL to safely free the DLL in which they are executing and terminate themselves. If they were to call FreeLibrary and ExitThread separately, a race condition would exist. The library could be unloaded before ExitThread is called.

---

Il suffit donc de gérer correctement (avec FreeLibraryAndExitThread donc) le déchargement de la DLL créatrice des threads secondaires.

Tout cela me semble bien compliqué et alambiqué.
Un thread doit toujours se terminer par lui-même c'est ce qu'il ya de plus conseillé.
Tu dois envoyer un message WM_USER ( avec SendMessge ) au thread et celui-ci doit le traiter et doit détecter ce WM_USER.
Et pas ce genre bricolage dont tu parles

Merci beaucoup de votre aide.
Bonne fin de journée

Bonjour,

Citation:

---

Envoyé par Mat.M

Tout cela me semble bien compliqué et alambiqué.
Un thread doit toujours se terminer par lui-même c'est ce qu'il ya de plus conseillé.
Tu dois envoyer un message WM_USER ( avec SendMessge ) au thread et celui-ci doit le traiter et doit détecter ce WM_USER.
Et pas ce genre bricolage dont tu parles

---

Je ne suis pas d'accord Mat.M.
On peut très bien imaginer un "worker thread" (thread de travail) qui attend soit un évènement - au sens Win32 de EVENT - particulier pour traiter quelque chose, soit un moment particulier pour entrer en jeu. Dans ces deux cas le thread boucle indéfiniment en attente de quelque chose à faire (thread "d'écoute").

Le problème auquel semble faire face le P.O est que si la DLL vient à être déchargée, il veut mettre fin proprement à ses threads - je suppose, pour éviter une possibilité de Race condition -, ce qui n'est pas possible (condition de deadlock) au moment du traitement de DLL_PROCESS_DETACH dans DllMain.

De plus les worker threads n'ont pas de pompe à message - puisque pas de fenêtre attachée - donc ils ne reçoivent aucun message window (WM_xxx).

En tout cas c'est ce qu'il me semble avoir compris du problème original, mais je peux me tromper.

Effectivement, c'est un peu cela. Les threads crées a l'intérieur de la DLL boucle infiniement (évidement) a chaque 20 ms vérifient l'état d'une boolèenne. Si cette booléenne est vraie, ils se suicident.
Cette variable est mise a vraie (demande de suicide de thread) lors de l'appelle a DLLMain et PROCESS_DETACH.

Hors, a cette étape, les threads ne semblent plus fonctionner et donc ne se suicident pas.
Les réponses ci-dessus semblent être un bon début de réponse a ma question.

Merci

Citation:

---

Envoyé par SebROLLE

Si cette booléenne est vraie, ils se suicident.
Cette variable est mise a vraie (demande de suicide de thread) lors de l'appelle a DLLMain et PROCESS_DETACH.

---

A ce moment-là c'est un problème d'accès aux variables et moins d'exécution de thread.
D'après ce que je comprends ce booléen n'est pas ou mal verrouillé, plusieurs processus y accèdent.
Il faut utiliser des sections critiques et verrouiller le booléen le cas échéant avec EnterCriticalSection et LeaveCriticalSection
:D