Comment arrêter automatiquement des threads à la fin du programme principal?

Salut

J'ai une "pool de threads" que je voudrais arrêter à la fin de l'exécution du programme principal. Plutôt que de le faire explicitement par un appel à une fonction, je voudrais le faire automatiquement.

J'ai pensé mettre cet appel dans le destructeur d'une classe statique, malheureusement ça ne marche pas: le destructeur de la classe n'est pas appelé une fois le main fini, sans doute parce qu'il reste des threads actifs (en attente).

Je ne sais pas si c'est faisable d'une manière ou d'une autre.
Des idées?

Je ne m'y connait pas trop en threads et c++, mais peut etre que tu peux passer par un exe externe pour faire un arret violent par l'intermediaire d'un batch que tu lances depuis ton main a la fin....

A ce moment la tu utilise la navigation par les menus dans ton batch pour aller arreter l'arborescence des processus de l'executable donne.
(J'utilisais cette manipe pour aller taper sur les cartes réseaux non accessible par le framework sous 2000pro)
Si tu veux l'exemple pour les cartes reseaux fais le mois savoir j'irais chercher le code....

++

Citation:

---

Envoyé par Charlemagne

J'ai pensé mettre cet appel dans le destructeur d'une classe statique, malheureusement ça ne marche pas: le destructeur de la classe n'est pas appelé une fois le main fini, sans doute parce qu'il reste des threads actifs (en attente).

---

Tu es sûr ? Je reste dubitatif, la fonction main est une fonction comme les autres et les destructeurs seront appelés. main n'est même pas en réalité la première fonction à être exécuté et n'est donc pas la dernière ;) (il y a pas exemple _start sous Unix)

J'ai déjà écrit un code d'une classe du genre : ThreadGroup qui permet de rejoindre tous les threads dans le destructeur, et ça marche sans problème

Citation:

---

Envoyé par millie

Tu es sûr ? Je reste dubitatif, la fonction main est une fonction comme les autres et les destructeurs seront appelés. main n'est même pas en réalité la première fonction à être exécuté et n'est donc pas la dernière ;) (il y a pas exemple _start sous Unix)

---

Je suis entierement d'accord pour le main. Apres etre sur, je te repondrais que j'ai effectue quelquechose de ce genre pour la gestion de cartes reseaux, en navigant par l'intermediaire d'un script dans les menus, et ainsi faire comme avec la souris.... Mais je n'ai pas dit que c'etait la meilleure solution... La tienne :

Citation:

---

Envoyé par millie

J'ai déjà écrit un code d'une classe du genre : ThreadGroup qui permet de rejoindre tous les threads dans le destructeur, et ça marche sans problème

---

est plus elegante et sera surement de meilleur qualité.

rikau2

@ Rikau2: J'exclue ta proposition d'un exécutable externe, je veux une solution 100% C++.

Citation:

---

Envoyé par millie

Tu es sûr ? Je reste dubitatif, la fonction main est une fonction comme les autres et les destructeurs seront appelés. main n'est même pas en réalité la première fonction à être exécuté et n'est donc pas la dernière ;) (il y a pas exemple _start sous Unix)

---

J'étais sûr, mais maintenant je le suis moins. (j'ai compilé avec Intel C++ Compiler sous Windows)
Je vais encore vérifier...

Citation:

---

Envoyé par millie

J'ai déjà écrit un code d'une classe du genre : ThreadGroup qui permet de rejoindre tous les threads dans le destructeur, et ça marche sans problème

---

Et le destructeur est appelé si tu fais une instance statique?

Oui oui, bien sûr. Sur un code comme ça par exemple :

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

class MonThread : public GThread {   private: int n;   public: MonThread(int a) { n=a; } void run() { for(int j=0; j<5; j++) { for(int i = 0; i<1000;i++) { // sleep(1); std::cerr<<"Thread numero : "<<n<<std::endl; }   waitAllGroup(); } }   };   static ThreadGroup group;   int main (void) {   group.add(new MonThread(0)); group.add(new MonThread(1)); group.startAll();   return EXIT_SUCCESS; }

---

Le destructeur affiche bien un message au moment ou tous les threads ont été rejoints ;)

EDIT : A noter que le destructeur est appelé avant la fin des threads. Mais je les attend, donc il finit après la mort de tous les threads.

C'est bien le principe que je comptais utiliser.

Ma vérification risque de durer un peu (j'ai fais des modifs non terminées dans ma gestion de threads)

Je comprends pas trop.
Qu'une classe statique n'appelle pas son destructeur je peux l'imaginer (j'ai déja eu bien des blagues avec les instances statiques), mais la question est pourquoi mettre ça en statique? Ton pool de threads est sensé être une classe maintenant une liste de réfèrence vers des threads, tu met bètemment dans son destructeur une boucle pour les interrompre et une autre pour faire un join dessus, et tu instancies ce pool au début de ton main.

C'est une pool que j'ai mise dans une librairie, je veux que ce soit aussi transparent que possible et c'est pour ça que je voudrais éviter au programme utilisateur de faire des initialisations ou finalisations autant que possible.
Les threads du pools sont susceptibles d'être utilisés à divers endroits dans le programme principal.

Je vois mieux la situation, malheureusement en C++ j'ai déja eu de belles abhérations en essayant d'utiliser ce genre de système, alors qu'en Java ça fonctionnera toujours à merveille. Non, sérieusement, je sais que ça fait pas clean mais pour pas se casser la tête et avoir un truc qui fonctionnera toujours il vaut mieux les utiliser quand même ces initialiations/finalisations (ou mieux, un peu de RAII pour être sur que la fonction de finalisation sera bien appelée), si tu le marques en gros dans ta doc ça posera pas de problème (tu n'imagines pas le nombre de biblio qui font la même chose).

Je ne sais pas trop ce qu'est ta classe statique dans ta bibliothèque, mais il est fort possible que le linker décide qu'il s'agit d'un objet non utile et le supprime. Essaye de mettre cette instance dans le programme principal, pour voir si c'est ça. Il y a probablement moyen de forcer le linker à ne pas éliminer un objet (à condition d'avoir son nom décoré...), mais ça ne répond plus aux critères de simplicité.

Citation:

---

Envoyé par zais_ethael

Je vois mieux la situation, malheureusement en C++ j'ai déja eu de belles abhérations en essayant d'utiliser ce genre de système, alors qu'en Java ça fonctionnera toujours à merveille. Non, sérieusement, je sais que ça fait pas clean mais pour pas se casser la tête et avoir un truc qui fonctionnera toujours il vaut mieux les utiliser quand même ces initialiations/finalisations (ou mieux, un peu de RAII pour être sur que la fonction de finalisation sera bien appelée), si tu le marques en gros dans ta doc ça posera pas de problème (tu n'imagines pas le nombre de biblio qui font la même chose).

---

J'avais encore jamais eu d'abhérations avec les classes statiques. Le seul problème potentiel que je leur connaisse vient du fait que l'ordre de leur initialisation/destruction peut varier d'un compilo à l'autre, mais dans mon cas y'a pas de dépendance vis à vis de l'ordre.

J'ai vu effectivement pas mal de bibliothèque exigeant de telles initialisations/finalisations. Je déteste!

Citation:

---

Envoyé par JolyLoic

Je ne sais pas trop ce qu'est ta classe statique dans ta bibliothèque, mais il est fort possible que le linker décide qu'il s'agit d'un objet non utile et le supprime

---

A priori, ça vient pas de là vu que j'utilise pas le linker. (C'est une variable statique dans un fichier header). Et puis la classe statique n'avait probablement pas été considérée comme inutile puisqu'elle avait été initialisé.


Je n'ai pas encore fini la réorganisation de ma gestion des threads dans ma bibliothèque. Quand je serai près, je vous en dirai plus sur ma vérification de destruction automatique des variables statiques. (mauvais timing avec l'ouverture de cette discussion). A vous lire, je dois reconnaître que j'ai un doute maintenant.

J’ai vérifié et effectivement les destructeurs des classes statiques sont bien appelés.
Désolé pour la fausse alerte…

En fait j’ai été confronté au problème que les classes statiques étaient détruites dans le « mauvais » ordre. Sans rentrer trop dans les détails, il y avait 2 classes statiques :
- groupe de threads
- un manager
Le destructeur des threads était appelé en premier, il attend en vain la fin d’exécution de threads qui attendent.
Le destructeur du manager, chargé d’envoyer des événements pour arrêter l’attente des threads, n’était jamais appelé.

J'ai une question, j'ai vu que tu étais l'auteur de Genial. Tu voulais utiliser les threads pour répartir les calculs sur plusieurs threads ? (pour cette bibliothèque)

Il y a énormement d'opérateur (de traitement d"images) qui se prête bien à ce jeu, dans ma bibliothèque, j'ai eu des gain énorme (benchmark sur des Sparc bi et quadri processeurs, temps d'exécution qui diminuait de 3.5) ;)

Citation:

---

Envoyé par millie

J'ai une question, j'ai vu que tu étais l'auteur de Genial. Tu voulais utiliser les threads pour répartir les calculs sur plusieurs threads ? (pour cette bibliothèque)

---

Oui.
Je pense rendre les calculs parallèles de manière plus ou moins transparente, un peu comme le sont déjà les calculs vectoriels SIMD.

Citation:

---

Envoyé par millie

Il y a énormement d'opérateur (de traitement d"images) qui se prête bien à ce jeu, dans ma bibliothèque, j'ai eu des gain énorme (benchmark sur des Sparc bi et quadri processeurs, temps d'exécution qui diminuait de 3.5) ;)

---

Dans un premier temps je mettrai à disposition des algorithmes de parallélisation, inspirés quelque peu de la bibliothèque d'Intel TBB.
Viendront par la suite plusieurs algos déjà disponibles dans ma bibliothèque:FFT, GEMM, Motion Estimation.

Comme dans ton cas, j'espère bien avoir un gain proche du nombre de processeurs.