Un thread de travail qui se termine et se libère tout seul

Salut !

Je suis confronté à un problème un peu bloquant, donc je vous en fait part:

Disons que j'ai dans mon application une classe Données qui permet de stocker des données.... on peut donc, par son interface publique, en ajouter et y accéder. Comme ces données peuvent provenir de plusieurs sources, et que le remplissage dot être asynchrone, j'ai délégué cette mission à des threads, selon le schéma suivant:

http://i2.photobucket.com/albums/y31...ck/donnees.gif

Voici donc mon problème :
Dans le thread principal, je créé à la fois une instance de Données, et une instance d'un flux pour l'alimenter. Données n'a pas connaissance de ce flux, parcequ'elle n'a pas à savoir qui la remplit, ce n'est pas son problème :wink:

Comment faire, donc, pour que FluxDonneesFichier soit libéré de la mémoire quand il a fini son travail ? J'ai bien tenté le delete this; à la fin de la méthode run(), mais visiblement, le fait de désallouer de la mémoire qui a été allouée dans un autre thread pose problème... :cry:

Comment faire donc, sachant que je ne veux pas trop casser la modularité du truc (mon idée de départ c'était "je créé un thread pour remplir les données, et je ne m'en occupe plus du tout")...

Est-ce que vous avez des idées ?
Merci!
:D

Quant tu créé un objet, un thread comme n'importe quel objet, tu garde une trace de l'adresse de celui-ci non ? Si tu en le fait pas tu devrais le faire, ton problème serait résolu.
Sinon, quand un thread se termine, il peut lancer un évennement attraper par le thread pricipal, mais peut-être n'a tu pas prévu de système d'évennement.

Un delete this; est à éviter absolument car un objet ignore s'il a été alloué dynamiquement ou pas. Une telle instruction exécutée dans un objet de la pile, c'est le drame ;-).

Citation:

---

Envoyé par Selenite

Un delete this; est à éviter absolument car un objet ignore s'il a été alloué dynamiquement ou pas. Une telle instruction exécutée dans un objet de la pile, c'est le drame ;-).

---

Ouh c'est vrai ;)
En fait j'avais mis le destructeur en membre privé, pour éviter qu'elle puisse être contruite sur la pile... mais c'est peut-être pas top comme astuce.

Sinon, oui il faudrait que je fasse ce système d'événement.... mais conceptuellement ça m'embete que les données connaissent la classe qui les remplit.... mais bon après c'est sur le schéma, on ne peut peut-être pas faire autrement dans la réalité ;)

Ce genre de choses n'est pas prévue dans ton API de MT ?

<message subliminal>Avec ACE (LA usine à gaz portable pour réseaux et MT), il me semble qu'il y a plusieurs façons de préparer des données qui seront envoyées à un autre thread; le courant étant tranquillement et automatiquement libéré une fois qu'il a fini son boulot.</>

Merci !

J'ai juste une question: qu'est ce qu'une MT (ou un MT peut-être ;) ) ?
Enfin je vais regarder du coté de ACE (http://www.cs.wustl.edu/~schmidt/ACE.html), puisque

Citation:

---

le courant étant tranquillement et automatiquement libéré une fois qu'il a fini son boulot.

---

c'est exactement ce que je cherche :)

Sinon, sous Win32, j'utilise habituellement un thread Win32 (créé par CreateThread, et non pas en utilisant un objet CWinThread/TThread) pour faire ça : ça se comporte comme une fonction, mais c'est un thread.
Une fois lancé, il est autonome, crée éventuellement son instance d'objet, la libère, et une fois terminé, le thread meurt de sa belle mort si le thread créateur a bien pensé à fermer le handle dessus... Un simple flag mis à jour via un InterlockedIncrement suffit à signaler la fin du thread pour un polling simplissime (ou utiliser un évènement, ça marche aussi bien entendu).

Citation:

---

J'ai juste une question: qu'est ce qu'une MT (ou un MT peut-être :wink: ) ?

---

Multi-Threading, sans doute.

Citation:

---

Envoyé par Loulou24

Multi-Threading, sans doute.

---

Ah oui, suis-je bête ;)

Citation:

---

Envoyé par Mac LAK

Sinon, sous Win32, j'utilise habituellement un thread Win32 : ça se comporte comme une fonction, mais c'est un thread.

---

Meric, je pense que c'est ce que je cherche! En effet, la fonction ne pose pas de problème de mémoire (0 allocation pour créer le thread, donc pas besoin de le détruire par un delete quelconque)...

Le seul problème, c'est que c'est pour une bibliothèque multi-plateforme :cry: :cry: Du coup je vais chercher un équivalent portable, mais tout ce que j'ai trouvé de portable pour l'instant, ce sont des classes de type CThread donc on hérite pour redéfinir une méthode run() ..... J'ai hate qu'il y ait du C++ standard pour tout ce qui est threads, réseau, et j'en passe... (j'espère que c'est prévu, au moins à très long terme :D )

Comme j'avais également besoin de gèrer le multi-tâche de manière portable (Windows et Linux), je me suis créée une bibliothèque qui propose une fonction prenant deux paramètres. D'une part, un pointeur sur la fonction à lancer dans un autre thread, et, d'autre part, un autre pointeur que la dite fonction reçoit en paramètre. Cette bibliothèque s'appuie sur pthread_create sous Linux et _beginthread sous Windows.
Pour plus de détails, voir la bibliothèque mtk sur le site http://epeios.org/. La documentation est , comment dire ..., extrêmement succinte, mais elle sera enrichie au fil des questions.
Soit dit en passant, sur ce même site, il y a également des bibliothèques gèrant des fonctionnalités réseau de manière tout aussi portable ...

Ah merci :)

Je vais aller voir tout ça, ça à l'air vraiment très complet comme biliothèque (MTK à l'air d'en n'être qu' 1/100 ème ....). Je ne sais pas si je pourrai l'utiliser (c'est pour un projet commercial, donc la licence GNU poserait problème, et les responsables du projet ne sont pas vraiment pour l'utilisation d'une bibliothèque externe), mais ça pourra au moins, dans tous les cas, me donner des idées ;)

Je vous tiendrai au courant !

Mon heuristique pour décider de la bibliothèque, portable, de threads à utiliser.
- Pour un programme qui a une IHM graphique (portable) => threads de l'API graphique
- Pour un prog orienté réseau et à forte consonnance Temps Réel => ACE
- Boost autrement (note en passant: on donne une fonction (via boost::function) aux threads créés avec boost, on n'en dérive pas pour spécialiser une quelconque function virtuelle)

(aucune licence virale avec cette heuristique -- mis à part les IHM avec QT si on ne côtise pas)

HTH.

Mmmm, je suis bien embeté, parceque

* l'IHM est en MFC, et elle est entièrement séparée du reste de l'application (biliothèque multi-plateforme qui regroupe l'ensemble des fonctionnalités).

* Le programme n'est pas trop orienté réseau, il y a juste une petite classe qui fait du réseau dans son coin (un plugin)

* On utilise VC6 (et on n'a pas le choix, c'est au boulot), donc c'est raté pour Boost :(

Pourquoiiiiiiiiiiiiii est-ce si difficile ? :cry: :wink:
Enfin je vais voir pour ACE, on peut peut-être se limiter a une petite partie de la bibliothèque. Enfin merci pour tous ces conseils !

Au boulot, on utilise boost et VC6 ensemble. Bien sur, on utilise par tout boost (par exemple spirit aurait bien du mal), mais les threads marchent avec VC6.

Ah, c'est n'est peut-être pas perdu ...

Il va falloir que je reflechisse pour voir si l'intégration de la partie Thread de Boost ne va pas être trop longue (le projet est quand même assez avancé, il y a juste ce problème d'auto-libération du flux de remplissage).

Enfin, dans l'absolu, cela ne devrait pas coûter grand chose, puisqu'il faudrait simplement remplacer la dérivation d'une classe threadée par une fonction threadée...

En tout cas merci pour cette précision! Je regarderai ca demain....

Bonjour,
Hmmmm concernant les lib de Thread Standard.... Posix Thread me semble la plus standard.
Elle a le mérite d'exister sur toutes les platformes...unix, linux Windows...peut être sous mac...à voire
Bye

Ah, merci pour cette nouvelle piste !
Je suis sur un autre point en ce moment, mais je regarderai ça dans les jours qui viennent.