Threads et C++

Bonjour,

Non je n'utilise pas boost.


Je voulais savoir, lorsqu'on détruit un thread avec le méchant KillThread() d'une bibliothèque C, est-ce que les destructeurs ont le temps d'être appelé? Sinon je risque de me retrouver avec un problème avec les strings...

De même, est-ce que si on appelle une fonction dans le thread, elle se termine même si on tue le thread? (Par exemple si je fais une fonction dangereuse du genre un string::swap(), y'a-t-il des risques?)

Merci de votre aide :)

KillThread n'est pas une fonction C standard, je ne sais pas de quelle bibliothèque elle vient. La réponse peut dépendre.

Si elle est vraiment "méchante", la réponse est non : Tout s'arrête de suite, rien d'autre ne s'exécute. La mémoire n'est pas libérée, les mutex restent pris,... En général, si ton but n'est pas de quitter le programme juste après, tant pis pour toi.

Après, il existe des fonction assassine qui au lieu d'y aller au bazooka utilise un poison lent, qui permet au thread en question de se rendre compte qu'il va mourir et de préparer sa succession (voire de prendre un antidote). Une possibilité pour ça est de générer une exception ou équivalent dans le thread en cours, ce signal remontant la pile d'appel et laissant donc un nettoyage se faire. La difficulté principale de cette méthode est de déterminer quand l'émission de cette exception peut se faire sans nuire au thread. Un problème connexe est qu'il est possible que le thread mettre très longtemps à mourir, voire refuse de le faire.

Je ne connais pas KillThread() non plus, mais TerminateThread() correspond exactement à la description de JolyLoic.

Cf les remarques de TerminateThread() si cette fonction t'intéresse.

Merci pour vos réponses.

En fait c'est la fonction SDL_KillThread de SDL, en téléchargeant le source j'ai vu:

Code:

---

1 2 3 4 5 6 7 8

/* WARNING: This function is really a last resort.  * Threads should be signaled and then exit by themselves.  * TerminateThread() doesn't perform stack and DLL cleanup.  */ void SDL_SYS_KillThread(SDL_Thread *thread) { TerminateThread(thread->handle, FALSE); }

---

Voilà...
En fait c'est TerminateThread, dans le lien donné par spoutspout il est dit:

Citation:

---

Envoyé par MSDN

TerminateThread is used to cause a thread to exit. When this occurs, the target thread has no chance to execute any user-mode code. DLLs attached to the thread are not notified that the thread is terminating. The system frees the thread's initial stack.

---

Donc la pile est nettoyée, c'est déjà ça, mais je pense que je vais éviter au maximum de l'utiliser (juste un pointeur sur classe), quitte à faire un thread dans un autre pour gérer les mutex etc. proprement.

Je n'ai pas très bien compris ce qui arrive avec les DLLs, est-ce que ça pose problème si j'utilise une fonction d'une DLL? Par exemple si j'utilise la fonction SDLNet_TCP_Send, qui est bloquante, et que je kill le thread, la fonction SDLNet_TCP_Send continuera de s'exécuter (car elle appartient à une DLL)??

Je commence à avoir l'impression que je vais devoir totalement changer d'outils pour le réseau -- si les fonctions SDL Send et Recv peuvent bloquer longtemps -- car SDL_KillThread n'a pas l'air gentille du tout.

Merci encore de votre aide,

coyotte507

Citation:

---

Envoyé par coyotte507

Par exemple si j'utilise la fonction SDLNet_TCP_Send, qui est bloquante, et que je kill le thread, la fonction SDLNet_TCP_Send continuera de s'exécuter (car elle appartient à une DLL)??

---

C'est exactement comme ça que je l'ai compris ;).

Une fonction n'est pas un thread....

Bloquant ca veut dire: "attend un signal d'un authre thread quelque part", c'est tout... si ton thread est dans la fonction SDLNet_TCP_Send, et que tu le tues, ben voilà, c'est tout, tu le tues... l'autre thread va bien envoyer son signal, mais y aura personne pour l'écouter.

Je ne connait pas SDL mais quelques idées pour ton problème:
-> Plutôt que d'utiliser un brutal KillThread tu peux mettre en place un mécanisme de demande de fermeture de ton thred. Celui-ci peut alors se terminer correctement. A toi de gérer les blocages.
-> Plutôt que d'avoir des TCPSDLNet_TCP_Send/Rcv en mode bloquant, tu peux t'appuyer sur des sockets non bloquantes et utiliser le select et/ou des API spécifiques pour attendre (type WSAWaitForMultipleEvents sur Windows).

Citation:

---

Envoyé par nicroman

Une fonction n'est pas un thread....

Bloquant ca veut dire: "attend un signal d'un authre thread quelque part", c'est tout... si ton thread est dans la fonction SDLNet_TCP_Send, et que tu le tues, ben voilà, c'est tout, tu le tues... l'autre thread va bien envoyer son signal, mais y aura personne pour l'écouter.

---

Si c'est le thread qui appelle la fonction dans la DLL, (l'exécution se trouve alors dans la DLL) et que le thread appelant est killé pendant ce temps là, la DLL n'est pas tenue au courant de la mort du thread et continue jusqu'au retour de la fonction de la DLL utilisée je suppose.
D'où le problème si la fonction est bloquante (sans parler du timeout).

Car un EXE/DLL et une autre DLL sont tout de même des "composants" différents qui vivent leur vie chacun de leur côté.

Citation:

---

Envoyé par Spout

Si c'est le thread qui appelle la fonction dans la DLL, (l'exécution se trouve alors dans la DLL) et que le thread appelant est killé pendant ce temps là, la DLL n'est pas tenue au courant de la mort du thread et continue jusqu'au retour de la fonction de la DLL utilisée je suppose.
D'où le problème si la fonction est bloquante (sans parler du timeout).

Car un EXE/DLL et une autre DLL sont tout de même des "composants" différents qui vivent leur vie chacun de leur côté.

---

Euh, t'es sûr de ça. Pour moi, le contexte d'exécution est lié à un processus avec ses threads. L'application et les DLL ne sont que du code chargé en mémoire. Si ton thread appelle une fonction dans une DLL, et que ton thread est tué, alors son exécution s'arrête même si le code en cours d'exécution était celui de la DLL. Le risque que je vois est plutôt lié à la non libération des ressources de ton thread.

Citation:

---

Envoyé par 3DArchi

Euh, t'es sûr de ça.

---

Pas complètement :aie:

Citation:

---

Envoyé par 3DArchi

Pour moi, le contexte d'exécution est lié à un processus avec ses threads. L'application et les DLL ne sont que du code chargé en mémoire. Si ton thread appelle une fonction dans une DLL, et que ton thread est tué, alors son exécution s'arrête même si le code en cours d'exécution était celui de la DLL.

---

Je comprends ce que tu veux dire, mais mon doute concerne les DLL avec leur propre classe applicative (par exemple CWinApp des MFC), pas celle qui n'exportent que des fonctions avec une interface C.
Alors comment interprètes-tu ça:

Citation:

---

Envoyé par MSDN

DLLs attached to the thread are not notified that the thread is terminating.

---

Citation:

---

Envoyé par 3DArchi

Le risque que je vois est plutôt lié à la non libération des ressources de ton thread.

---

Egalement.

Citation:

---

Envoyé par Spout

Je comprends ce que tu veux dire, mais mon doute concerne les DLL avec leur propre classe applicative (par exemple CWinApp des MFC), pas celle qui n'exportent que des fonctions avec une interface C.

---

A mon sens, il n'y a pas de création d'un nouveau process/thread donc l'exécution se poursuit dans le contexte actuel. Mais je vois ce que tu veux dire: CWinApp dérive de CWinThread-> donc création implicite d'un thread. En fait, il faut passer par CWinThread::CreateThread pour créer le thread, l'instanciation d'un CWinThread ne suffit pas. Et ça n'a pas l'air d'être le cas. Je ne suis pas sûr de mon coup, mais en croisant différentes infos du MSDN, je persiste à dire qu'il n'y a pas de création de thread implicite lors du chargement d'une quelconque DLL.

Citation:

---

Envoyé par Spout

Alors comment interprètes-tu ça:

Citation:

---

Envoyé par MSDN

DLLs attached to the thread are not notified that the thread is terminating.

---

---

Que tu ne passeras pas par ExitInstance/DllMain(DLL_THREAD_DETACH). Donc, tu auras bien un problème de libération de ressources.

Attention, "The system frees the thread's initial stack" signifie que la mémoire brute de la pile dudit thread est libérée. Aucun destructeur n'est appelé...

Un thread est un mécanisme de système d'exploitation pas de liaison direct avec le langage C++ qui lui ne permet pas la gestion des threads (nativement).

En outre la seule façon (légale) d'appeler un destructeur est d'appeler un des deux opérateurs du langage C++, soit delete soit delete [] (si le ou les objets ont été crées avec "new").

Il est donc très probable qu'une API type "KillThread" (que je ne connais pas d'ailleurs) n'appelle jamais un destructeur, et de toute façon si elle le faisait, le design de cette architecture serait très contestable.

Dans la plupart des systèmes à base de threads, quand une de ces unités d'exécution est démarrée une pile est allouée (de taille déterminable en général). Quand le thread est détruit la pile est relachée. ;)

Bonsoir

Citation:

---

Envoyé par Médinoc

Attention, "The system frees the thread's initial stack" signifie que la mémoire brute de la pile dudit thread est libérée. Aucun destructeur n'est appelé...

---

C'est ce que j'avais compris aussi :(...

J'ai regardé la source de SDL_net (jusqu'où faut aller faire des vérifications!) et donc apparement les fonctions SDLNet_TCP_Send et SDLNet_TCP_Recv peuvent s'exécuter en un laps de temps assez court, quand on les appelle au bon moment, donc de ce côté là ça va... je les mettrais quand même dans un thread, mais j'aurais pas besoin de le tuer.

J'ai compris les risques avec TerminateThread, la prudence exigée lorsqu'on l'utilise -- je ne connaissais pas les risques d'appeler une fonction DLL, et il n'y a pas de moyen de détacher une DLL d'un thread avec SDL uniquement (peut-être que sous linux y'a pas ce genre de problème ?).

En gros, grâce à tous les renseignements obtenus, je pense avoir trouvé le moyen d'implémenter mon projet, sans changer de bibliothèque :mrgreen:

Merci beaucoup à vous tous! :merci:

coyotte507

Citation:

---

Envoyé par Profman

En outre la seule façon (légale) d'appeler un destructeur est d'appeler un des deux opérateurs du langage C++, soit delete soit delete [] (si le ou les objets ont été crées avec "new").

---

Depuis quand?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <string> #include <stdlib.h> #include <iostream> #include <ostream>   using namespace std;   int main() { void* ptr = malloc(sizeof(string)); std::string* bar = new(ptr) string("Hello world\n"); std::cout << *bar; bar->~string(); free(ptr); }

---

me semble parfaitement conforme, aux typos près. C'est la technique utilisée normalement dans les conteneurs (difficile par exemple d'implémenter std::vector<T>::reserve() si on ne n'utilise pas).

Citation:

---

Envoyé par Jean-Marc.Bourguet

Depuis quand?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <string> #include <stdlib.h> #include <iostream> #include <ostream>   using namespace std;   int main() { void* ptr = malloc(sizeof(string)); std::string* bar = new(ptr) string("Hello world\n"); std::cout << *bar; bar->~string(); free(ptr); }

---

me semble parfaitement conforme, aux typos près. C'est la technique utilisée normalement dans les conteneurs (difficile par exemple d'implémenter std::vector<T>::reserve() si on ne n'utilise pas).

---

La franchement c'est ce que j'appel de la grosse bidouille !!

Appeler un destructeur "à la main", evidement on peut mais très dangereux dans un code pro.

De plus je ne vois pas l'intérêt de ce code : allouer la taille de la string avec "malloc', appeler le destructeur explicitement et libérer avec "free" trop fort.

Pourquoi ne pas utiliser que "new" et "delete" c'est fait pour ça : ça alloue et appel les bons mécanismes au bon moment.

Comme indiqué par Jean-Marc, c'est rare de devoir mettre ça en place, mais ça peut servir. Imagine par exemple qu'avec un seul malloc (ou un new "non typé") on peut réserver de la place contiguë pour 100 objets, mais ne créer qu'un objet dans un premier temps, puis créer les autres à la demande, sans plus avoir besoin d'allouer de mémoire. C'est ce que fait std::vector en interne.

Il y a encore une autre façon légale d'appeler un destructeur, c'est certainement même la plus courante ;) :

Code:

---

1 2 3

{ A a; } <- Le destructeur de A est appelé...

---

Citation:

---

Envoyé par JolyLoic

Code:

---

1 2 3

{ A a; } <- Le destructeur de A est appelé...

---

---

Hehe oui c'est vrai ;) La pile reste une valeur sûre.

Un autre truc pas mal c'est d'utiliser un smart pointer qui se chargera de faire le delete. Mais c'est vrai que cette bête là ne plaît pas à tous 8-)

Ici un exemple avec le smart pointer de boost :

Code:

---

1 2 3 4 5 6 7 8 9

class X; int main() { boost::scoped_ptr<X> spx( new X() ); return 1; } // ici le destructeur de 'spx' entrainera la libération

---

Citation:

---

Envoyé par JolyLoic

Comme indiqué par Jean-Marc, c'est rare de devoir mettre ça en place, mais ça peut servir. Imagine par exemple qu'avec un seul malloc (ou un new "non typé") on peut réserver de la place contiguë pour 100 objets, mais ne créer qu'un objet dans un premier temps, puis créer les autres à la demande, sans plus avoir besoin d'allouer de mémoire.

---

Pratique très courante dans le développement de jeu vidéo par exemple, surtout sur console.

Une surcharge de new et delete sera plus élégante dans une telle situation.

Elle ppurra meme fournir des infos en mode debug.

Pas dans le cas d'utilisation de certaines libs, ou quand tu veux budgetter tes différentes parties...

Un article de blog (en français) et des commentaires très interessants sur le sujet : http://jeremy.chatelaine.name/blog/?p=36

L'article présentant la EASTL a un chapitre résumant des contraintes qu'on a aussi dans le jeu vidéo, et qui expliquent les modifications/ajouts qu'ils proposent.

Pouvoir appeler le constructeur et le destructeur manuellement est bien entendu très intéressant dès qu'on a déjà la mémoire sur laquelle on veut placer l'objet...
Par exemple, comment implémenter sans allocation dynamique boost::optional sans ça ?

Citation:

---

Envoyé par Profman

La franchement c'est ce que j'appel de la grosse bidouille !!

---

Non, c'est une technique de bas niveau utile pour implémenter certaines abstractions, ce n'est pas tout a fait la même chose. A nouveau, implémente quelque chose de similaire a vector sans cela.

Citation:

---

De plus je ne vois pas l'intérêt de ce code : allouer la taille de la string avec "malloc', appeler le destructeur explicitement et libérer avec "free" trop fort.

Pourquoi ne pas utiliser que "new" et "delete" c'est fait pour ça : ça alloue et appel les bons mécanismes au bon moment.

---

Il y a une différence entre montrer comme mettre en œuvre une technique et expliquer dans quel contexte il faut le faire. J'étais a mon avis clairement dans le premier cas. J'aurais pu utiliser ::operator new() et ::operator delete() a la place de malloc et free, ça n'aurais rien change sur le fond ni sur ce que je voulais montrer, et ça introduisait quelque chose de plus qui risquait d'être non familier a certains.

Citation:

---

Envoyé par deadalnix

Une surcharge de new et delete sera plus élégante dans une telle situation.

---

Je ne fais pas tricher et te demander une implémentation conforme de vector qui n'utilise pas cette technique (les specs de l'allocateur l'impose :-)) mais j'aimerais bien voir comment tu implémenterais élégamment et sans appel explicite au destructeur un pop_back qui détruit bien sans libérer la mémoire. Je vois bien un moyen ou deux, mais ça me semble tous des hacks bien plus gros que l'appel explicite au destructeur, ça revient fondamentalement à cela et je ne suis même pas sur de la conformité formelle d'un détail.

+1 avec jean marc, boost::variant, boost::optional et std::vector sont des exemples typiques de ce genre de chose. Ca arrive de le faire, c'est pour ca que le placement new existe.

new -> delete
new[] -> delete []
new(void*) -> ~T()

Un truc que j'aimerais bien savoir, c'est si ce code est garanti marcher, ou bien s'il faut systématiquement faire les deux appels.

Je me doute que pour un tableau, c'est à ne surtout pas faire, mais pour un seul objet ?

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

class Nimp { public: int m_value;   Nimp(int value); ~Nimp(void); };   void TestNew(void) { Nimp *pNimp = static_cast< Nimp * >(::operator new(sizeof(Nimp))); new(pNimp) Nimp(42);   //Test: Un simple delete au lieu de appel au destructeur + operator delete delete pNimp; }   Nimp::Nimp(int value) : m_value(value) { std::cout << "<Nimp ctor=\"" << m_value << "\">" << std::endl; } Nimp::~Nimp(void) { std::cout << "</Nimp>" << std::endl; }

---

En tout cas, ca marche chez moi avec VC. En fait, je dirais que ca marche à partir du moment où tu remplit les conditions suivantes:
-> La zone mémoire a été correctement initialisé au regarde de l'objet, i.d. t'es passé au - une fois dans un constructeur de Nimp, ---> donc l'appel au destructeur se fera avec un objet valide
-> La zone mémoire a été allouée de façon compatible avec le 'free' lié au delete ---> le delete sait libérer la mémoire.

Citation:

---

Envoyé par Médinoc

Un truc que j'aimerais bien savoir, c'est si ce code est garanti marcher, ou bien s'il faut systématiquement faire les deux appels.

---

A priori c'est conforme tant que tu n'as pas d'operator delete dans la classe ou une classe de base.

Merci.