Probleme avec la mise en place de thread

Bonjour, je développe une application avec MFC (VS8) pour du calcul scientifique 3D (physique des particules). Les calculs sont longs, voir très longs (des dizaines de jours). Aujourd'hui, le schéma de fonctionnement suivant est utilisé pour chaque calcul :

- CBoiteDeDialogueCalculA de CDialog (avec champs d'initialisation, progressbar, ...)
- CCalculA qui effectue le calcul proprement dit (avec une ribanbelle de classes appelées) et interagit avec la progressbar.

- dans CMainFrame, lié à un menu :
- Déclaration de CboiteDeDialogueCalculA
- DoModal() et la boite dialogue prend le relais

=> Le calcul freezera rapidement la boite de dialogue, voire toute l'appli !!!

La solution est d'ajouter du multi-threading ;o)

Ok, je lance désormais les calculs comme des nouveaux thread, cad :
- dans CboiteDeDialogueCalculA, je lance la fonction de calcul :
AfxBeginThread( MaFonctionDeCalcul, CboiteDeDialogueCalculA*)

=> Le calcul se lance, tout commence bien, la progressBar, les textes informatifs de la boite de dialogue et, de facon aléatoire, ca plante sur le DoModal lancé dans le CMainFrame et à des endroits différents dans le code du DoModal ???
Je suis un peu paumé avec les possibilités et la manière de s'y prendre pour le multi-threading, c'est ma première fois... J'ai essayé en ouvrant ma boite de dialogue en Create() pour que le GUI principal reste accessible, mais dans ce cas ce sont les fonctions d'auto-update de l'interface (OnUpdateEditCut, OnUpdateEditPaste,...) qui plantent...

Merci de partager votre expérience sur cet épineux problème !
Jc.

Sur le principe ça ne paraît pas déconnant !!!

En général, plantage aléatoire à différents moments = jardinage.

Vérifie que les données de ton thread ne débordent pas.

Ce genre de problème est très courant pour les débutants.

Si le programme vous semble bon, pas de connerie comme des pointeurs utilisées n'importe comment, la cas le plus fréquent est un problème de mise à jours concurrente de données dans les contrôles Windows.

Les contrôles Windows ne sont pas threadsafe. S'ils sont accédés par plusieurs threads cela provoque des plantages "aléatoires" pour le néophyte.

Vérifiez que vous ne modifiez le contenu affiché par les contrôles que depuis le thread qui les a créé.

Pour des calcules de plusieurs jours, je n'aurais pas fait du multithreading, j'aurais isolé ces traitement long dans un autre processus, comme dans un Service Windows qui peut tourner sans personne de connecté et dispose d'un mécanisme de reprise sur erreur intégré au système. En plus, cela serait étanche et donc il n'y aurait pas de problème d'accès concurrent aux contrôles Windows. Il faudra juste utiliser des IPC pour communiquer avec le Service Windows.

Excuse moi pour une précision sur le vocabulaire :
- Jardinage ?
- les données ne débordent pas ?

Merci pour ton aide

Est ce que le service Windows que tu décrits pourrait etre à meme de mettre a jour l'affichage 3D des trajectoires calculées au fur et à mesure de l'avancement de la simulation, c'est ainsi que cela fonctionne aujourd'hui ?

Je déduis que je dois effectivement faire des accés concurrents à des espaces mémoires, l'objet instancié gérant le calcul (Thread) utilisant des propriétés du doc et du mainframe qui sont aussi utilisés par l'affichage...

Aie !je pensais que Windows se démerdait comme un grand avec cela...

Cela signifie que il me faut dupliquer toutes les données utilisées en meme temps pour la partie affichage et la partie calcul (modele 3D avec géométrie, propriétés physiques, d'affichage) : c'est énorme ! Il s'agit de modele 3D de satellites ou d'engin spatiaux en général, détaillés jusqu'aux composants electroniques.
N'y a-t-il pas un procédé pour partager ces données sans les dupliquer en mémoire ? Si c'est effectivement ce qu'il faut faire...
MErci

Jardinage : ta partie calcul va taper dans la mémoire de ta partie affichage sans que tu le désires.

Citation:

---

Envoyé par jcloupgarou

N'y a-t-il pas un procédé pour partager ces données sans les dupliquer en mémoire ? Si c'est effectivement ce qu'il faut faire...
MErci

---

Surtout pas dupliquer !!!!!
tu peux ne pas dupliquer, par contre, tes threads pointent sur la même zone mémoire, donc il ne faut pas qu'ils y touchent (écriture/lecture) en même temps. Tu dois mettre en place une section critique.

Merci pour vos remarques trés interessantes !

Pour plus de précision, cette appli fait prés d'un million de lignes de C++ partagées en centaines de classes qui évoluent depuis une dizaine d'années.
Le multi threading n'avait pas été envisagé jusqu'alors, mais cela parait incontournable aujourd'hui pour optimiser la vitesse de nos simu et la convivialité du soft (anti-freeze).
Un calcul est défini par un modele 3D avec des caractéristiques géométriques et physiques, un environnement de calcul( parametres, liste de materiaux, .... ). Tous ces éléments sont affichés par l'interface principal sous la forme d'une arborescence pour la hierarchie du modele 3D, un contexte opengl pour le viewer 3D, des dialogues ancrés pour les propriétés. Il y a dans tous les sens ;o)

Par exemple, l'entité géométrique de base est un "CComposant" : le viewer le dessine (une boite par exemple), son nom apparait dans l'arborescence, les dialogs de l'interface affichent son nom, son matériau, sa couleur, sa position, ... et dans le meme temps, l'algo de calcul va devoir calculer une arborescence de boites englobantes à partir de ces "CComposant" (donc avoir accés à leur propriété geometriques, graphiques...), calculer des intersections rayon-CComposant, et appliquer des modeles physiques en fonction des materiaux rencontrées.

Ca parait ultra-complexe de mettre en place des sections critiques vu la quantité de références à ces objets déclarés dans mon CDocument par exemple et utilisés aussi par la fonction threadée !
Qu'en pensez vous svp ? Merci bcp !

Citation:

---

Pour plus de précision, cette appli fait prés d'un million de lignes de C++ partagées en centaines de classes qui évoluent depuis une dizaine d'années.

---

Bienvenue dans le monde du "poids de l'histoire" d'un logiciel. :aie:

Citation:

---

Envoyé par jcloupgarou

Ca parait ultra-complexe de mettre en place des sections critiques vu la quantité de références à ces objets déclarés dans mon CDocument par exemple et utilisés aussi par la fonction threadée !
Qu'en pensez vous svp ? Merci bcp !

---

Ca va être compliqué pour s'en rendre compte sans le code (ou diagramme des classe). On se doute que tu ne vas pas les mettre ici. ;)
Je trouve ça bizarre qu'un tel projet ne soit pas conçu en multi-thread vu qu'il y a un partie affichage et une autre partie calcul. A moins que la partie calcul soit très rapide (courte).

Ce logiciel a été concu et developpé par des physiciens à la base. J'ai repris le flambeau il y a quelques années, pour renforcer la partie 3D (modélisation, interaction, post-traitement 3D des résultats). Les calculs étaient moins gourmands en ressource car les modeles physiques trés simples et les modeles geometriques épurés. (quelques heures de calcul).
Maintenant, la géométrie est ultra comlpexe et les méthodes Monte-carlo utilisées pour simuler les interactions particules-matiere (réactions nulcéaires, electromagnétique, ionisation, ...) sont de plus en plus completes. Il faut tirer une quantité hallucinante de particules pour faire converger un résultat, donc un temps de calcul dément, de l'ordre de plusieurs semaines par exemple pour un modele de la taille d'un batiment/entrepot.
L'appli est organisée dans la philo CDocument, CView, CMainFrame et CApp :
- le CDoc contient la hierarchie du modele 3D, une liste de materiaux, de radio-materiaux,....
- le CView affiche le modele et gere l'interactivité (souris, clavier,...)
- le CMainFrame donne acces au différents outils (menu, contextmenu) : de modélisation ( insertion d'objets 3D, import de fichiers (STEP, IGES,...), ...), de calcul (différents types de calcul, par RayTracing, par MonteCarlo), et de post-traitement (cartographie, histograming, ...)

Pour chacun des calculs, une classe CClasseCalcul est déclarée dans la classe gérant le dialogue d'initialisation/execution CClasseCalculDlg : des pointeurs vers le CDocument, le CView et le CMainFrame sont passés à CClasseCalcul pour qu'elle puisse manipuler la géométrie et d'autres attributs du CDoc, rafraichir le viewer 3D en fonction des résultats intermédiaires (trajectoires de particules, mapping,...) ou mettre à jour des messages textuels sur l'interface pour signifier l'avancement du calcul à l'utilisateur.

La mise en place de section critiques ou autre mutex impacterait tout le code ou presque. Rien que pour l'affichage du modele 3D pendant le calcul sur ce meme modele, cela touche des dizaines de fonctions dans plusieurs classes et ce n'est qu'un exemple...

Vous semblez présenter le modèle Document/Vue standard des applications MFC non boite de dialogue.

Vous subissez peut-être "le poids de l'histoire", mais là, je pense que vous avez droit au géant de Newton. ;)

Vous disposez d'un modèle qui sépare rigoureusement les données de l'affichage.
Normalement, vos calcules modifient les données et vos vues sont notifiez via message que le document a changé (UpdateAllViews).
Vous n'avez donc cas mettre en œuvre un verrouillage de type lecteurs-écrivains sur les données localisées dans l'objet Document.

Si vous avez des problèmes d'accès concurrents, avec ce modèle, c'est que vous ne l'avez suivi à la lettre. (A moins qu'UpdateAllViews a changé d'implémentation)

Ok, merci ! J'ai compris pas mal de trucs sur les threads, merci messieurs.
J'ai réussi à m'en sortir en déplacant toutes mes initialisations de pointeurs dans la partie du calcul "threadée". Tout marche désormais sur des roulettes, plus de "freeze" (ne répond pas) de l'application pendant les calculs longs, la progress bar et les messages sont bien affichées et les boutons "arret" et "pause" de la boite de dialogue gérant le calcul sont trés réactifs !!! Il faut que j'applique ce schéma à tous les calculs proposés par l'appli.
Encore merci, bonne route à vous !