Discussion :

[contremaitre]

Bonjour,

J'explique mon problème qui est un peu complexe :
Je crée une classe thread générique qui fonctionne ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
class Thread
{
     friend void * _starter(void * data);
     bool		Start();
     virtual void task() ; //tache principale qui doit etre redefinie
};
 
class MonThread : public Thread
{
    virtual void task();
};

le constructeur de Thread apelle Start() qui crée le thread avec pthread_create et _starter avec en argument data this

_starter apelle la fonction task() qui est redéfinie dans ma classe MonThread qui herite de la classe Thread.

Le probleme c'est que la fonction task apellée dans _starter est celle de la classe Thread et non celle redéfinie dans ma nouvelle classe MonThread.
J'ai compris que c'est parce que lors de la création de l'objet thread la fonction task redéfinie n'existe pas encore donc il apelle celle de base.
J'ai trouvé un moyen de contourner le probleme en mettant un sleep(1) juste avant d'apeller task() dans ma classe thread. Du coup il apelle bien la fonction redéfinie.
Y a t'il un moyen plus propre de faire ca, comme par exemple en attendant la création de l'objet avant d'apeller la fonction autrement que par un sleep ?

merci

[Laurent Gomila]

Tu ne devrais juste pas lancer le thread dans son constructeur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MonThread t; // --> ne fait rien
t.Start(); // --> appelle pthread_create, _starter et tout le tralala

PS : autant mettre _starter en static privée dans Thread, elle n'a d'utilité que dans cette classe.

[contremaitre]

Oui j'y avais pensé, mais j'essayai de pouvoir tout lancer seulement en créant l'objet.

Quand au static privé, si je le fait alors je n'ai plus accès aux variables privées de ma classe dans starter, et j'en ai besoin (exemple : un booléen running que je met a true dans starter)

[Laurent Gomila]

Oui j'y avais pensé, mais j'essayai de pouvoir tout lancer seulement en créant l'objet.

Bien que ce soit généralement une bonne idée, dans ce cas là c'en est une mauvaise
Par exemple, comment tu fais si tu as un thread en donnée membre, pour qu'il ne se lance pas dès la construction de l'objet parent ? Ou si tu veux démarrer le thread dans une portée plus courte que la durée de vie souhaitée du thread (par exemple un bloc if) ? Ce que tu veux faire est une contrainte beaucoup trop pénalisante.
Si tu n'es toujours pas convaincu jette un oeil à toutes les bibliothèques qui fournissent une telle classe : le lancement du thread est toujours séparé de sa construction.

Quand au static privé, si je le fait alors je n'ai plus accès aux variables privées de ma classe dans starter, et j'en ai besoin (exemple : un booléen running que je met a true dans starter)

Justement si, puisque _starter sera alors membre de Thread.

[contremaitre]

Tu m'as convaincu :p

Par contre :

Justement si, puisque _starter sera alors membre de Thread.

Thread.cpp:18: error: cannot declare member function ‘static void* Thread::_starter(void*)’ to have static linkage

[dtrosset]

A noter une implémentation un peu différente qui diminue le couplage entre l'objet de thread et l'execution qui est faite. Il faut avoir une classe d'interface threadable, dont on définit une classe personalisée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
class threadable {
public:
    virtual void execute(void *data) = 0;
};
 
class mon_threadable {
public:
    virtual void execute(void *data);
};

Et puis on définit une classe qui execute ces objets threadable.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
class threader {
public:
    void start(threadable *thread);
};

C'est cette fonction threader qui gère et donc crée les threads en appelant thread_create. Et c'est lors de l'appel de threader.start() que la fonction membre threadable.execute() est appelée dans un autre thread d'exécution.

A noter que cela offre l'avantage de pouvoir implémenter le threader différemment selon ses besoins. On peut ainsi utiliser un pool de thread pour les réutiliser et ne pas en créer un nouveau à chaque fois qu'il faut exécuter un nouveau threadable.

Enfin, l'implémentation du threader est complètement séparée du threadable. Aussi, la durée de vie des objets de threadable et threader peuvent être différente. Tout ceci diminue le couplage.

[JolyLoic]

Dans ce cas là, autant utiliser boost::function, c'est encore plus flexible.

[Laurent Gomila]

Pour l'erreur avec static, il ne faut pas répéter le mot "static" dans le .cpp.

[contremaitre]

Ha oui ça marche mieux

Merci pour les conseils.

et merci aussi à dtrosset pour l'idée ça permet de voir une autre possibilité.

Car je n'ai pas rouvé beaucoup d'exemples de classes de thread en C++, et les quelques que j'ai trouvées contiennent souvent pas mal d'erreurs.
Celle dont j'ai pris exemple est ici, pour info :
http://www.codeguru.com/cpp/cpp/cpp_...php/c14447__5/

Je fait ceci car j'ai besoin d'une classe générique pour créer facilement des classes "threadés" sans librairies tierces.

[JolyLoic]

As-tu regardé boost::thread ?

[contremaitre]

Oui, mais comme je disais juste au dessus :
Je fait ceci car j'ai besoin d'une classe générique pour créer facilement des classes "threadés" sans librairies tierces.

[JolyLoic]

Ce n'est pas possible. Le C++ ne possède pas la notion de thread, tu es obligé de passer par une bibliothèque tierce pour en créer. Et tant qu'à faire, autant utiliser boost::thread, qui est de bonne qualité, portable, et proche de ce que seront les threads gérées directement en C++ le jour où elles existeront.

[screetch]

entre une dependance sur boost et une dependance sur pthread, il y a un pas que je n'ai jamais reussi a franchir. boost tire la moitié du monde avec lui...