IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MFC Discussion :

Probleme avec la mise en place de thread


Sujet :

MFC

  1. #1
    Membre confirmé
    Inscrit en
    Janvier 2006
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 99
    Par défaut 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.

  2. #2
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2011
    Messages
    1 255
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 255
    Par défaut
    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.

  3. #3
    Expert confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 472
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 472
    Par défaut
    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.

  4. #4
    Membre confirmé
    Inscrit en
    Janvier 2006
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 99
    Par défaut
    Excuse moi pour une précision sur le vocabulaire :
    - Jardinage ?
    - les données ne débordent pas ?

    Merci pour ton aide

  5. #5
    Membre confirmé
    Inscrit en
    Janvier 2006
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 99
    Par défaut
    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...

  6. #6
    Membre confirmé
    Inscrit en
    Janvier 2006
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 99
    Par défaut
    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

  7. #7
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2011
    Messages
    1 255
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 255
    Par défaut
    Jardinage : ta partie calcul va taper dans la mémoire de ta partie affichage sans que tu le désires.
    Citation Envoyé par jcloupgarou Voir le message
    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.

  8. #8
    Membre confirmé
    Inscrit en
    Janvier 2006
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 99
    Par défaut
    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 !

  9. #9
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2011
    Messages
    1 255
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 255
    Par défaut
    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.
    Citation Envoyé par jcloupgarou Voir le message
    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).

  10. #10
    Membre confirmé
    Inscrit en
    Janvier 2006
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 99
    Par défaut
    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...

  11. #11
    Expert confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 472
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 472
    Par défaut
    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)

  12. #12
    Membre confirmé
    Inscrit en
    Janvier 2006
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 99
    Par défaut
    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 !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. probleme avec la mise à jour
    Par j_esti dans le forum Hibernate
    Réponses: 6
    Dernier message: 24/06/2008, 14h16
  2. probleme avec la mise en veille prolongée
    Par ABN84 dans le forum Windows XP
    Réponses: 7
    Dernier message: 25/11/2007, 23h45
  3. [openSuse10.3] problem avec les mises a jour
    Par wodel dans le forum SUSE
    Réponses: 2
    Dernier message: 20/11/2007, 10h06
  4. Réponses: 8
    Dernier message: 09/09/2007, 12h52
  5. Réponses: 1
    Dernier message: 30/03/2007, 16h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo