multithread, singleton et exit

**yan** · 25/11/2017, 16h35

Bonjour.
j'ai une dll qui utilise un singleton pour manager des ressources. Ces ressources instancient des std::thread, std::mutex et std::shared_mutex.

Le singleton est instanci� lors de l'appel � une fonction static

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
class singleton
{
public
    static singleton &current()
   {
        static singleton _singl;
        return _singl
   }
};

Malheureusement, ceci pose probl�me si un utilisateur appel la m�thode exit().

Lors de l'appel � exit, la destruction du singleton crash car les thread se sont arr�t�s sans lib�rer les mutex.
La seule mani�re que j'ai trouv�e est de modifier l'instanciation du singleton en utilisant un pointeur et d'ajout� une fonction pour le d�truire(doit �tre appel� par l'utilisateur avant de sortir du main). Mais lors d'un exit rien n'est lib�r� proprement.

Y a t'il une possibilit� d�emp�cher l�arr�t brutale des thread lors de l'appel � un exit et de pouvoir lib�rer proprement les donn�es de ma dll?

merci,
Yan

**Pyramidev** · 25/11/2017, 17h35

Bonjour,

La solution est probablement de remplacer l'appel de exit par le lancement d'une exception.
Si le code utilise correctement le RAII, alors les ressources seront lib�r�es au fur et � mesure que l'on remonte dans la pile.

**Bktero** · 25/11/2017, 18h16

Est-ce que atexit() pourrait te permettre d'enregistrer une fonction pour g�rer ce cas ?

http://man7.org/linux/man-pages/man3/atexit.3.html

**yan** · 25/11/2017, 18h38

Envoy� par Pyramidev

Bonjour,

La solution est probablement de remplacer l'appel de exit par le lancement d'une exception.
Si le code utilise correctement le RAII, alors les ressources seront lib�r�es au fur et � mesure que l'on remonte dans la pile.

Je n'ai pas vraiment la main sur ces parties de code :/. Mais �a serait plus propre.

Envoy� par Bktero

Est-ce que atexit() pourrait te permettre d'enregistrer une fonction pour g�rer ce cas ?

http://man7.org/linux/man-pages/man3/atexit.3.html

Cette fonction est appel�e apr�s l�arr�t des thread :/

merci

**bacelar** · 27/11/2017, 16h17

Il est tr�s commun de demander � l'utilisateur d'une librairie d'appeler une m�thode avant toute demande, comme le CoInitialize() de COM, et apr�s la derni�re demande comme CoUninitialize() de COM.
Donc pourquoi ne pas demander au code utilisateur de votre biblioth�que de faire de m�me ?

L'utilisation de la fonction DllMain ne permet-elle pas un repli en bonne ordre ?

Apr�s, il reste toujours les m�thodes de bourrins, � la virus, qui est de d�router l'IAT de "exit" du programme pour que votre Dll prennent la main, mais bon, on peut commencer par gentiment demander � l'utilisateur de ne pas faire n'importe quoi, avant de sortie la bombe atomique.

**yan** · 27/11/2017, 20h59

Envoy� par bacelar

L'utilisation de la fonction DllMain ne permet-elle pas un repli en bonne ordre ?

ben non car il y a des choses que l'on ne dois pas faire dans dllmain

et pas forcement appel� lors de la sortie du process.

Donc pourquoi ne pas demander au code utilisateur de votre biblioth�que de faire de m�me ?

En faite j'ai une fonction qui nettoie les ressources allou�es � appeler avant le return du main.
Mais je ne m'attendais pas � ce que exit(appel� par une autre lib...) pose probl�me.
Au finale, je n'avais pas pens� que lors de l'appel � un exit, les thread sont arr�t�s automatiquement par le syst�me et peut laisser des mutex bloqu� et donc ne plus pouvoir d�sallouer certaines classe constitu�es de std::thread ,std::mutex,...

Et donc devoir g�rer le singleton diff�remment que

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
class singleton
{
public
    static singleton &current()
   {
        static singleton _singl;
        return _singl
   }
};

pour avoir des cas o� on ne le d�truit pas.

**foetus** · 27/11/2017, 21h15

Envoy� par yan

Au finale, je n'avais pas pens� que lors de l'appel � un exit, les thread sont arr�t�s automatiquement par le syst�me

Lorsque tu quittes, ce n'est pas le thread principal (ou le thread de la .dll) qui envoie un message "quit"/ "stop"/ ... � tous les threads cr��s ?

**yan** · 27/11/2017, 23h12

Envoy� par foetus

Lorsque tu quittes, ce n'est pas le thread principal (ou le thread de la .dll) qui envoie un message "quit"/ "stop"/ ... � tous les threads cr��s ?

je ne sais vraiment qui fait quoi :/.
Mais lorsque le destructeur du singleton de ma dll �tait appel�, les thread n�existaient plus et des mutex �taient lock�=>crash.

[edit]
j'ai ajout� un exemple. Si vous ajoutez un breakpoint dans le destructeur du singleton, il ne reste que la main thread. Les autres sont kill� et les mutex encore lock�.

**bacelar** · 28/11/2017, 18h09

Je suis vraiment pas fan des API en C++ pour les Dll, moi, c'est plus des API C en Dll, quitte � fournir des classes templates pour faire des wrappper.

Avec une API C, le coup du CoInitialize()/CoUninitialize() passe bien.

Sinon, une approche un peu moins bourrin que planquer/d�router la fonction "exit" de l'IAT est donn�e par THE Jeffrey Richter (2�me Q/R):
https://www.microsoft.com/msj/archive/S202B.aspx

P.S.: si l'approche de Jeffrey Richter vous semble obscure, n'h�sitez pas � poser des questions ici.

**yan** · 29/11/2017, 21h36

Envoy� par bacelar

P.S.: si l'approche de Jeffrey Richter vous semble obscure, n'h�sitez pas � poser des questions ici.

Je veux bien un peu plus d'explication

**bacelar** · 30/11/2017, 19h16

Bon, apr�s une relecture plus attentive de vos messages et de l'article de MSJ, et apr�s un petit potassage de la litt�rature, la solution de Jeffrey Richter, bien que "simple" � mettre en place, ne sera pas bonne dans votre cas, voir m�me catastrophique.
Le comportement en fin d'ex�cution d'un processus change beaucoup entre les diff�rentes versions de Windows.
Avez-vous une plateforme cible pr�cise ? Cela donnerait plus de libert� et de possibilit�s.

Si j'en crois les articles sur le sujet par Raymond Chen (Win32 pas sur l'impl�mentation dans la SDL), les mutex c'est les trucs les plus simple � "g�rer" dans le cas d'une fin de programme.
https://blogs.msdn.microsoft.com/old...03-00/?p=27003 (Attention, article plus � jour, il y a eu des modifications sur la mani�re dont le processus g�re les sections critiques depuis).
En gros, pour les mutex, �a marche tout seul, il parait.
J'ai test� votre code sur un vieux VS2012 qui traine en changeant le chaine de compilation vers la version v110 et j'ai bien un abort en DEBUG sur le destructeur du mutex,.
Mais cet abort n'est qu'un "sanity check" pour indiquer que c'est pas bien d'appeler le destructeur quand son compteur interne n'est pas � 0. Mais ici, ce compteur n'est pas � jour car le Kernel a d�j� automatiquement lib�rer le mutex.
En Release, pas de probl�me, �a roule.

Avec ces informations, c'est quoi le probl�me pr�cis�ment, qui n'est pas g�rer "automatiquement" ?

Un exemple de patching d'IAT :
https://blog.neteril.org/blog/2016/1...-iat-patching/
Ici, �a serait de patcher la m�thode "exit" ou �quivalent. (mais c'est vrai que le atexit est plus direct)
Mais, vous pouvez pas patcher cette foutue lib qui appel "exit" comme un putain de sauvage ???

**yan** · 03/12/2017, 10h23

En Release, pas de probl�me, �a roule.

exit se tranforme en abort... donc c'est pas mieux.

Envoy� par bacelar

Avec ces informations, c'est quoi le probl�me pr�cis�ment, qui n'est pas g�rer "automatiquement" ?

que exit killmes std::thread sans que je n'ai aucun contr�le => des mutex ne sont pas lib�r� =>erreur.

Envoy� par bacelar

Un exemple de patching d'IAT :
https://blog.neteril.org/blog/2016/1...-iat-patching/
Ici, �a serait de patcher la m�thode "exit" ou �quivalent. (mais c'est vrai que le atexit est plus direct)

atexit est appel� apr�s le kill des thread. Pour 'IAT, je suis �tonn� que l'on peux faire des choses comme cela sans qu'un anti virus le bloque.

Envoy� par bacelar

Mais, vous pouvez pas patcher cette foutue lib qui appel "exit" comme un putain de sauvage ???

Tout est possible avec les bon arguments

mais le but est aussi de comprendre. Je pensais qu'en utilisant les std::lock_guard et autre, des probl�mes comme cela n'�tait pas possible. Apr�s plusieurs recherche, �� s'appel des mutex abandonn� et les std::mutex ne l'impl�mente pas.
�a montre surtout que le exit n'est pas compatible avec le c++ moderne et l'utilisation du RAII.

**bacelar** · 04/12/2017, 12h05

exit se tranforme en abort... donc c'est pas mieux.

Il n'y a pas d'abort en Release, en tout cas dans mon impl�mentation de la C-Runtime VS2012.

que exit killmes std::thread sans que je n'ai aucun contr�le => des mutex ne sont pas lib�r� =>erreur.

Ils le sont par le Kernel, c'est juste que la C-Runtime ne le sait pas et que la version DEBUG n'en est pas consciente et gueule.

atexit est appel� apr�s le kill des thread

Oui, comme le DllMain, et alors ?

Pour 'IAT, je suis �tonn� que l'on peux faire des choses comme cela sans qu'un anti virus le bloque.

Si tu savais.

Non, g�n�ralement, les anti-virus n'y voient que du feu.
Et tu peux exclure ton environnement de travail des zones de scan de l'anti-virus, au pire.

�� s'appel des mutex abandonn� et les std::mutex ne l'impl�mente pas.

Oui, mais c'est pas grave, ils utilisent ceux du Kernel qui lui l'impl�mente.

�a montre surtout que le exit n'est pas compatible avec le c++ moderne et l'utilisation du RAII.

"exit" n'est compatible avec absolument rien, depuis l'invention de la programmation structur�e, il y a fort longtemps.
"exit" c'est CACA.

Je ne comprends toujours pas pourquoi ne pas juste laisser pisser, en Release.

**yan** · 04/12/2017, 20h54

Envoy� par bacelar

Il n'y a pas d'abort en Release, en tout cas dans mon impl�mentation de la C-Runtime VS2012.

?? ben ca appel abort et stop le process.

Oui, comme le DllMain, et alors ?

�� r�sout pas mon probl�me. si c'�tait appel� avant le kill des thread, j'aurais pu faire le m�nage proprement

Oui, mais c'est pas grave, ils utilisent ceux du Kernel qui lui l'impl�mente.

si je les lock pour une raison ou une autre je me retrouve bloqu� ind�finiment. C'est le comportement des mutex de la std qui ne semble pas �tre juste un wrapper au vieux mutex.

Je ne comprends toujours pas pourquoi ne pas juste laisser pisser, en Release.

par ce que j'aime bien comprendre

et que j'aurais pr�f�r� pouvoir nettoyer sans faire des bidouilles.

**bacelar** · 05/12/2017, 12h40

?? ben ca appel abort et stop le process.

�a c'est en DEBUG, pas en RELEASE.
Et pour la fin de processus, n'y a-t-il pas autre chose que des mutex, comme des sections critiques, ou du code qui touche � ces mutex apr�s la fin des threads satellites ?

�� r�sout pas mon probl�me. si c'�tait appel� avant le kill des thread, j'aurais pu faire le m�nage proprement

L'OS fait le travail pour toi, non ?

si je les lock pour une raison ou une autre je me retrouve bloqu� ind�finiment. C'est le comportement des mutex de la std qui ne semble pas �tre juste un wrapper au vieux mutex.

Il est bien plus probable que le blocage vienne de votre code qui attend des threads d�j� mort que d'�ventuels mutex.

par ce que j'aime bien comprendre et que j'aurais pr�f�r� pouvoir nettoyer sans faire des bidouilles.

La mani�re "propre", c'est de ne jamais appeler exit.
Il ne vous reste donc que les bidouilles.
La meilleure bidouille, c'est celle qui ne fait rien.
Normalement, en RELEASE, vous n'avez rien � faire.

Le comportement de l'OS est l� pour simplifier la t�che, et m�me ceux avec la t�te en l'air.

**yan** · 05/12/2017, 19h04

Exit c'est mal �a on est d'accord

Pour le reste, pas tout � fait.
Pour moi, dans le fonctionnement normal d'un processus c'est au d�veloppement de g�rer ses ressources et non a l'OS.

Mais bon le probl�me se pose � cause du exit ^^

**bacelar** · 05/12/2017, 20h07

c'est au d�veloppement de g�rer ses ressources et non a l'OS.

Si c'�tait vraiment le cas, les OS ne fonctionneraient correctement que vraiment tr�s tr�s peu de temps.

Moi, Windows3.0, j'en veux plus.

Maintenant, soyez un peu moins psycho-rigide.

Pour �viter que l'OS soit en carafe parce qu'une �quipe de d�veloppeurs ne s'est pas mise d'accord avec une autre, l'OS a fait SON job : dessouder tous les threads sauf un, lib�rer tous les mutex, "�lectrifier" les sections critiques (elles sont "libres", mais si le code y entre, c'est "process shutdown sans passer par la case d�part, vous ne touchez pas 20 milles"), etc... .

C'est � vous de faire le v�tre, qui, en RELEASE est "rien" (merci les "concepteurs" de l'OS qui sont vraiment tr�s gentils avec les d�veloppeurs �tourdis), et en DEBUG faire les bidouilles pour que sanity-check de la librairie passent cr�mes.

N'oubliez pas que le thread survivant est sur une autoroute, o� il ne doit pas attendre ces camarades et que tous les feux (verrous) sont aux verts, ce qui facilite grandement le code de "nettoyage".

**yan** · 05/12/2017, 21h14

Envoy� par bacelar

l'OS a fait SON job : dessouder tous les threads sauf un, lib�rer tous les mutex, "�lectrifier" les sections critiques (elles sont "libres", mais si le code y entre, c'est "process shutdown sans passer par la case d�part, vous ne touchez pas 20 milles"), etc... .

�� reste une strat�gie (laisser faire l'OS). Lors d'un crash de l'application �� ne me pose aucun probl�me.
Sinon a quoi se faire ..bip... avec toutes ces classes RAII ou autres outils?

Apr�s, la question de d�part �tait de comprendre le "pourquoi" pour savoir "quoi faire"

Le exit me stop net des traitements en cours dont j'aurais pr�f�r� g�rer l�arr�t moi m�me.

pour les info.

**Bousk** · 05/12/2017, 23h18

Envoy� par yan

Sinon a quoi se faire ..bip... avec toutes ces classes RAII ou autres outils?

A s'assurer du bon fonctionnement de l'appli tant qu'elle doit tourner, � commencer par ne pas consommer plus de m�moire et CPU que n�cessaire, voire que disponible. Quand elle doit s'arr�ter, on s'en moque royalement, on l'arr�te, quelle que soit la violence employ�e, et l'OS nettoie le tout bien.

**yan** · 06/12/2017, 11h21

Envoy� par Bousk

A s'assurer du bon fonctionnement de l'appli tant qu'elle doit tourner, � commencer par ne pas consommer plus de m�moire et CPU que n�cessaire, voire que disponible. Quand elle doit s'arr�ter, on s'en moque royalement, on l'arr�te, quelle que soit la violence employ�e, et l'OS nettoie le tout bien.

Que l'OS fasse sont travail est une chose, mais que je mes traitements s'arr�tent violemment sans que je puisse faire quelque chose en est une autre.

Je ne comprend pas trop ce qui vous g�ne en faite.

multithread, singleton et exit

Threads & Processus C++

Discussions similaires

Partager

Partager