Injection de multithread dans du code qui a 15 ans.

**Feriaman** · 11/12/2006, 18h18

Bonjours à nouveau,

Il m'a été confié la délicate mission de délocaliser dans des threads secondaires des parties d'un programme qui a déjà bien vécu.

Après avoir levé les bras bien haut et précisé que ce genre d'opération était risqué et que la délocalisation ne serait sans aucun doute que très partielle, j'ai mis ne place un ThreadManager qui sait lancer dans un nouveau thread une méthode avec des paramètres donnés, puis lorsque celui-ci est terminé, générer un évènement qui déclenchera une autre méthode dans mon thread principal.

Quelque chose comme :

Code :

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

1
2
3
4
5
6
7
8
class ThreadManager_core
{
public :
        template<       typename Class1, typename MethodForThread, typename ParamIn,
                        typename Class2, typename MethodAfterThread, typename ParamsOut
                >
        void createThread(Class1*, MethodForThread, ParamIn*,Class2*, MethodAfterThread, ParamsOut*,HWND, ProgressHandler* pHandler=NULL);          // lance un thread
}

Donc je peux transformer des codes comme :

Code :

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

1
2
3
4
5
void loadDatas(const std::string& sFileName)
{
   Datas newDatas = loadDatasInFile(sFileName);
   createViewOfDatas(newDatas);
}

en

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
void loadDatas(const std::string& sFileName)
{
   Datas newDatas;
   ThreadManager::get()->createThread(this,loadDatasInSecondaryThread,&sFileName,this,integrateDatas,&newDatas);
}
void loadDatasInSecondaryThread(const std::string& sFileName)
{
   Datas newDatas = loadDatasInFile(sFileName);
}
void integrateDatas(Datas newDatas)
{
   createViewOfDatas(newDatas);
}

La gestion des paramètres de mes deux méthodes est un peu plus complexe que cela, mais ce n'est pas ce qui nous intéresse ici.

Ceci marche bien tant que la méthode que l'on exécute dans le thread n'accède pas aux mêmes variables que celles de mon thread secondaire. Or je ne connais pas la moitié du code de l'application que je modifie.

J'ai réalisé un ThreadChecker qui vérifie que l'on est dans le thread principal. Et, si je suis cohérent, il me faut l'appeler partout dans mon programme, afin qu'il asserte si mes threads secondaires appelent des méthodes qui accèdent aux données de mon thread principal.

Ce qui veut dire : modifier toutes les méthodes de tous les fichiers de mon programme.

Avant de lançer ma moulinette qui va faire ça, je me demandais si quelqu'un envisageait une méthode plus class.
J'ai pensé un moment définir une macro "{", quelque chose comme :

Code :

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

# define { Tools::ThreadChecker::get()->checkThatYouAreInTheMainThread();

Mais cela ne marchera pas, et puis cela promet de perdre tout futur codeur qui bossera sur le projet.

Merci par avance à ceux qui pourront m'aider.

**epsilon68** · 11/12/2006, 18h25

je te conseille boost::thread ... ne refais pas ce genre de chose...

**epsilon68** · 11/12/2006, 18h27

... utilise aussi openmp

il permet justement de profiter du multi-core pour des programmes existants, puisqu'il agit a un niveau assez fin, les boucles

openmp + boost::thread = pas mal d'ennuis en moins

**epsilon68** · 11/12/2006, 18h31

aussi cela ne sert a rien de deporter en multi thread des bouts de codes que de toute facon on attend dessus ....

as-tu des algos compliqués qui prennent du temps ?
Que veux-tu vraiment ameliorer en utilisant des threads secondaires ?

**Feriaman** · 11/12/2006, 18h33

Merci de ces si rapides réponses.

J'aurais du préciser dans le message d'origine que je n'ai pas le droit, pour des raisons de politiques de gestion de projet qui ne sont pas de mon ressort, d'utiliser boost, ni d'ailleurs la moindre librairie ou le moindre bout de code qui ne soit déjà partie intégrante de mon projet.

Merci tout de même

**Feriaman** · 11/12/2006, 18h37

Envoyé par epsilon68

aussi cela ne sert a rien de deporter en multi thread des bouts de codes que de toute facon on attend dessus ....
as-tu des algos compliqués qui prennent du temps ?
Que veux-tu vraiment ameliorer en utilisant des threads secondaires ?

Cela sert à pouvoir en lançer plusieurs à la fois, et à continuer d'utiliser l'IHM pendant ce temps.

Le logiciel en question manipule des données assez lourdes et que le chargement et certains calculs prennent parfois plusieurs minutes.

**epsilon68** · 11/12/2006, 18h39

c'est quoi comme IHM (Qt ? ... ? )

**Feriaman** · 11/12/2006, 18h39

C'est du MFC.

**epsilon68** · 11/12/2006, 18h41

parce que pas toutes les interfaces ne pourrait reagir a un evenement direct, mais plutot posté

**epsilon68** · 11/12/2006, 18h43

MFC alors il faut posté un evenement qui dit que tu as fini de charger le fichier ... ou le calcul ... ou n'importe quoi, surtout pas appeler de fonction directe

et quel compilateur ?

**Feriaman** · 11/12/2006, 18h47

Envoyé par epsilon68

MFC alors il faut posté un evenement qui dit que tu as fini de charger le fichier ... ou le calcul ... ou n'importe quoi, surtout pas appeler de fonction directe

On a du mal se comprendre, c'est exactement ce que je fais. Lors d'un appel de createThread la séquence est la suivante :
- création d'un thread secondaire
- le thread secondaire lance la première fonction
- le thread secondaire poste un message au thread primaire
- le thread primaire reçoit le message et lance la seconde fonction

C'est même pour cette raison que j'ai découpé en deux fonctions.
Mon problème est juste de vérifier que nulle part dans la première fonction on n'utilise des données accédées dans le thread principal.

Envoyé par epsilon68

et quel compilateur ?

Visual .net

**epsilon68** · 11/12/2006, 18h51

ok mais tu ne pourra jamais savoir si ta variable est utilisé dans d'autre threads, il te faut mettre des garde fous ...

vs.net 2005 ?

**loufoque** · 12/12/2006, 02h13

Utilise des processus plutôt que des threads si tu veux être sûr qu'il n'y ait pas d'accès concurrents à une variable.

**Feriaman** · 12/12/2006, 10h04

Envoyé par epsilon68

ok mais tu ne pourra jamais savoir si ta variable est utilisé dans d'autre threads, il te faut mettre des garde fous ...

Comme le code est vieux, volumineux et que je ne le connais que très partiellement, mettre des zones critiques et/ou mutex sur les diverses variables risque d'être plutôt fastidieux.
C'est bien là tout mon problème.

Autrement dir : faire clean est exclu, il faut faire vite.

Je penche donc vers un pis-aller qui est de me contenter de checker à l'exécution que
- seules les méthodes que je marque sont appelées dans les threads secondaires.
- aucune méthode que je marque n'est appelée dans un trhead primaire.

Ca ne garantis pas qu'il n'y aura pas un partage de mémoire malencontreux. Cela garantis que si je sais faire en sorte que les méthodes marquées ne touchent pas les même données que les méthodes non marquées, alors je n'aurais pas de partage malencontreux.

Mais je suis à la recherche d'une meilleure idée, tant que ça peut être réalisé sans comprendre le détail du code.

Envoyé par epsilon68

vs.net 2005 ?

Non 2003.

**epsilon68** · 12/12/2006, 10h23

Tu vas a peu pres droit dans le mur...

**Feriaman** · 12/12/2006, 12h00

Envoyé par epsilon68

Tu vas a peu pres droit dans le mur...

Oui, bien sur, il n'y a qu'une alternative : faire au propre ou ne rien faire.

Malheureusement, au quotidien, il faut souvent travailler à partir de code qui n'a pas été pensés comme tu le souhaitais, et ce sans avoir le temps de tout refaire.

Si tu connais d'autres conditions de travail, cela m'intéresse de savoir où tu bosses, j'enverrais un CV.

**epsilon68** · 12/12/2006, 12h56

:-)

**epsilon68** · 12/12/2006, 13h00

Envoyé par Feriaman

Oui, bien sur, il n'y a qu'une alternative : faire au propre ou ne rien faire.

Ce n'est pas tout l'un ou tout l'autre, mais dans des cas comme ca il faut pas foncer la tete la premiere et faire du code parce qu'il faut faire tout de suite.

Cela necessite du refactoring de code, comprendre abstraire.
"propre" ne veut en soi rien dire, il faut au moins que ce soit robuste.
mais faire pour faire, ca va tout le temps droit au mur. au final tu paniques pour ne rien gagner a la fin.

a+

**tut** · 12/12/2006, 13h20

faudrait que tu demandes à ton responsable s'il connait la différence entre l'informatique et la magie ?

Les solutions que tu veux mettre en place me semble un peu trop bricolées, hélas... ce n'est pas un jugement, mais je constate avec toi que tu es pris par le temps.
Peut-être que tu devrais prendre le problème d'un point de vue fonctionnel : "quand je fais telle opération, l'IHM est figée, qu'est-ce que je peux faire pour que ce ne soit plus le cas ?" plutôt que de vouloir tout changer en entier...

Sinon, pour le problème des variables partagées, j'ai écrit une classe il y'a quelques temps qui permettait de faire évoluer un attribut de classe de "normal" vers "protégé par un mutex" en ne changeant que 5-10 % du code où est utilisé l'attribut :

Code :

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

1
2
 
int m_MonAttribut;

devient :

Code :

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

1
2
 
JMMutex<int> m_MonAttribut;

et puis voila, l'attribut est "protégé" des lectures/écritures concourantes par Mutex.
Si ça peut t'aider je peux te l'envoyer => MP.
Bon courage, en tout cas....

**Feriaman** · 12/12/2006, 14h01

Merci de vos encouragements.

Envoyé par tut

faudrait que tu demandes à ton responsable s'il connait la différence entre l'informatique et la magie ?

J'ai commençé par prévenir du danger ... et des phrases comme : "non seulement le code que l'on va livrer provoquera peut-être des plantages impossible à diagnostiquer, mais en plus il est probable que ces plantages ne se produisent jamais pendant la phase de test" n'ont pas suffit à le décourager.

Donc je me dis qu'il sait ce qu'il veut. La décision étant prise, il me faut le réaliser. Actuellement ça marche sans aucune vérification du partage de la mémoire, et tout le monde s'en tamponne sauf moi ... j'aimerais quand même mettre en place rapidement un système qui permette, si ce n'est d'éviter le mur, au moins de le voir.

Envoyé par tut

Code :

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

1
2
 
JMMutex<int> m_MonAttribut;

Je devrais peut-être m'orienter vers quelque chose comme ça, mais plutot que de tout protéger par mutex (ce qui me provoquerait, presque à coup sur des deadlocks), garder un booléen qui m'indique si le thread dans lequel la variable est utilisée est le thread principal où non, et qui asserte en cas de problème.

Code :

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

1
2
3
4
5
6
7
8
 
template<typename T> AssertIfUsedBy2Threads
{
   private : 
      bool bMainThread;
   public : 
      /*l'ensemble de mes opérateurs*/
}