Thread -> WaitForSingleObject() && Application -> Bloquée

Bonjours à tous !

Je ne comprends pas bien le fonctionnement ci-après :

J'ai une fonction qui lance deux threads. Ces deux threads sont synchronisés entre eux. Normalement, pendant qu'ils s'exécutent, je devrais être censé pouvoir naviguer à souhait sur l'interface graphique de mon application. Néanmoins, l'usage de WaitForSingleObject m'empêche vraisemblablement de le faire : l'application est bloquée.

NB : Les deux threads sont exécutés de leur première à leur dernière instruction.

Sauriez-vous ce qui cloche ?

WaitForSingleObject fait attendre le thread qui l'appel jusqu'à ce que le handle en paramètre soit signalé.
Si le thread qui appel WaitForSingleObject est le thread graphique, l'affichage est bloqué.
Je pense que vous avez mal compris l'utilisation de WaitForSingleObject.

Bonjour,
le WaitForSingleObject est vraiment utile des le moment ou l'application va se fermer afin que tous les processus fils soit bien mort avant la mort du processus père afin d'éviter des problèmes de processus fantômes.

Citation:

---

Envoyé par bacelar

WaitForSingleObject fait attendre le thread qui l'appel jusqu'à ce que le handle en paramètre soit signalé.
Si le thread qui appel WaitForSingleObject est le thread graphique, l'affichage est bloqué.
Je pense que vous avez mal compris l'utilisation de WaitForSingleObject.

---

Hum... en fait, les deux threads sont complètement indépendants du thread graphique. Grosso modo, sur l'interface graphique il y a un bouton. C'est en cliquant sur ce bouton que les deux threads sont lancés, et pourtant toute l'application est bloquée. Je pense que tout ceci est causé par les appels à WaitForSingleObject().

Je signale des événements selon ce procédé :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Thread1 // Création de l'événement event1 [...] WaitForSingleObject(event1, INFINITE); ResetEvent(event1); [Opérations] SetEvent(event2); Thread2 // Création de l'événement event2 [Calculs] SetEvent(event2); WaitForSingleObject(event2,INFINITE); ResetEvent(event2);

---

Je précise que les événements sont créés à l'état non signalé. Ces deux threads sont donc plus ou moins bloquants, mais tout ça ne devrait pas bloquer l'application elle-même, si ?

@jouana : comment pourrais-je m'en passer dans mon cas ?

tu utilise quoi comme lib graphique??

Citation:

---

Envoyé par jouana

tu utilise quoi comme lib graphique??

---

MFC.

C'est pour lucratif un projet a but lucratif?
sinon y a Qt qui vaut le coup

Citation:

---

Envoyé par jouana

C'est pour lucratif un projet a but lucratif?
sinon y a Qt qui vaut le coup

---

C'est pour un logiciel métier qui est développé depuis 20 ans... :?

Et quant à mon problème, qu'en penses-tu ?

bah je ne connais pas trop MFC mais tu doit avoir des hook pour tes event a la place de tes threads c'est pas trop comme sa que tu fait de l'evenmentiel

Plusieurs remarques concernant ton pseudo code :

Code:

---

1 2 3 4 5 6 7

Thread1 // Création de l'événement event1 [...] WaitForSingleObject(event1, INFINITE); ResetEvent(event1); [Opérations] SetEvent(event2);

---

Si l'event2 n'est pas créé, SetEvent(event2) ne sert à rien (et génère une erreur). Ceci peut se produire si le thread2 n'est pas encore parti puisque c'est lui qui créé l'event2

Code:

---

1 2 3 4 5 6

Thread2 // Création de l'événement event2 [Calculs] SetEvent(event2); WaitForSingleObject(event2,INFINITE); ResetEvent(event2);

---

Le thread2 va partir immédiatement puisque l'event2 est positionné et ensuite on attend dessus avet de le resetter, c'est le but ?

Dans aucun des 2 thread je ne vois le SetEvent(event1), un oubli ou bien c'est fait ailleurs ?

En régle générale, avant de créer les thread, il faut créer les event

Il fait quoi, le thread graphique, après avoir créé les 2 autres threads ? :aie:

Citation:

---

Envoyé par ram-0000

Dans aucun des 2 thread je ne vois le SetEvent(event1), un oubli ou bien c'est fait ailleurs ?

---

C'était une erreur de ma part :

Code:

---

1 2 3 4 5 6

Thread2 // Création de l'événement event2 [Calculs] SetEvent(event1); WaitForSingleObject(event2,INFINITE); ResetEvent(event2);

---

C'est l'événement 1 que je signale ici. En amont dans le code, je crée un événement dans le thread 1 et j'attends qu'il soit signalé par le thread 2. Il est signalé après la création des événements qui seront utilisés. Dans le thread 1, j'utilise WaitForSingleObject() après avoir également créé les événements. En résumé, tous mes événements sont créés avant de procéder aux calculs et aux opérations.

@bacelar : Le thread graphique doit permettre à l'utilisateur de lancer d'autres opérations pendant que les deux autres tournent.

Hum... le problème vient peut-être du fait que le thread 1 met à jour une zone de l'interface graphique.

Edit : En fait j'essaye de mettre à jour une barre de progression en fonction de l'avancée d'un calcul. Ce qui serait terminé si il n'y avait pas ce caractère bloquant.

Citation:

---

Envoyé par Plumb

Hum... le problème vient peut-être du fait que le thread 1 met à jour une zone de l'interface graphique.

Edit : En fait j'essaye de mettre à jour une barre de progression en fonction de l'avancée d'un calcul. Ce qui serait terminé si il n'y avait pas ce caractère bloquant.

---

Il le fait comment en envoyant un message à l'interface graphique (Send/Post Message(WM_USER, ...)) ou bien en agissant directement sur l'interface graphique.

Pour info, il faut que ton thread envoie un message spécifique à l'interface graphique et l'interface graphique en recevant ce message spécifique va mettre à jour l'objet graphique.

Citation:

---

Envoyé par ram-0000

Il le fait comment en envoyant un message à l'interface graphique (Send/Post Message(WM_USER, ...)) ou bien en agissant directement sur l'interface graphique.

Pour info, il faut que ton thread envoie un message spécifique à l'interface graphique et l'interface graphique en recevant ce message spécifique va mettre à jour l'objet graphique.

---

J'utilise une redéfinition de la classe CProgressCtrl. Quand je modifie le champ texte de la barre de progression, par exemple, une fonction de redimensionnement est appelée. Dans le code je peux y lire des appels à UpdateWindow(), MoveWindow(). Après t'avoir lu, j'ai commenté les appels à la fonction pour changer le texte, et il ne restait que des fonctions de modification de la position, de pas, et des StepIt(), qui elles font directement appel aux fonctions de la classe mère CProgressCtrl. D'après le code source, cette classe (CProgressCtrl) fonctionne par envoi de messages.

C'est donc bien un problème lié à des modifications sur la fenêtre principale. Si dans mon thread 1 je commente tous les appels inhérents à la barre de progression, l'application n'est plus bloquée.

Un thread de travail (tes threads 1 et 2) sont probablement des thread de travail ou encore Working Thread ne doit pas modifier l'interface graphique.

Il doit :

• Envoyer un message spécifique à l'interface graphique WM_USER + x (à définir, c'est ton message utilisateur) avec des paramètres wParam et lParam qui permettent à l'interface graphique de savoir ce que veut le working thread. Pour cela, il faut que le working thread connaisse le handle HWND (et pas le CWnd *) de l'interface graphique. En général, c'est passé en paramètre lors de la création du thread.
• Ce message doit être envoyé par SendMessage ou PostMessage (SendMessage est bloquant et attend que le message soit traité par la l'interface graphique, PostMessage ne fait que poster et retourne immédiatement)
• L'interface graphique doit intercepter le message WM_USER + x dans le MESSAGE_MAP et faire le traitement en fonction des différents paramètres reçus (dans wParam et lParam)

Citation:

---

Envoyé par ram-0000

Un thread de travail (tes threads 1 et 2) sont probablement des thread de travail ou encore Working Thread ne doit pas modifier l'interface graphique.

Il doit :

• Envoyer un message spécifique à l'interface graphique WM_USER + x (à définir, c'est ton message utilisateur) avec des paramètres wParam et lParam qui permettent à l'interface graphique de savoir ce que veut le working thread. Pour cela, il faut que le working thread connaisse le handle HWND (et pas le CWnd *) de l'interface graphique. En général, c'est passé en paramètre lors de la création du thread.
• Ce message doit être envoyé par SendMessage ou PostMessage (SendMessage est bloquant et attend que le message soit traité par la l'interface graphique, PostMessage ne fait que poster et retourne immédiatement)
• L'interface graphique doit intercepter le message WM_USER + x dans le MESSAGE_MAP et faire le traitement en fonction des différents paramètres reçus (dans wParam et lParam)

---

De cette manière l'interface ne serait plus bloquée, même si elle est mise à jour ?

Je vais étudier tout ça, merci.

Citation:

---

Envoyé par Plumb

De cette manière l'interface ne serait plus bloquée, même si elle est mise à jour ?

---

L'interface fait son boulot de gestion des objets graphiques et du raffraichissement.

Les thread font leur boulot (du calcul ou de trucs de longue haleine) et de temps en temps envoient un message à l'interface graphique pour lui demander de mettre à jour un truc ou un bidule graphique.

C'est comme cela que cela doit marcher :P

Oui, mais pendant la mise à jour, l'utilisateur ne pourra toucher à rien dans l'interface ?

Si si, mais les événements sont sérialisés par l'interface graphique donc il n'y aura pas de conflit.

Par contre, là où il peut y avoir des problème c'est si tu as des boutons qui ont des actions contradictoires dans le genre "stop" du thread même si aucun thread n'est lancé au start d'un thread déjà lancé.

Dans ce cas, soit tu rajoutes des tests dans les fonctions de traitement des boutons, soit tu actives et désactives les boutons pour refléter l'état du système (ce que je ferais).

Il n'y a rien de pire que de cliquer sur le bouton "stop" et de prendre un message d'erreur "Pas de thread à stopper", autant désactiver le bouton.

Si mes souvenirs sont bons, c'est plus WM_USER + x mais WM_APP + x dû à de sombres histoires de framework additionnels. :aie:

Citation:

---

soit tu actives et désactives les boutons pour refléter l'état du système (ce que je ferais).

---

Pour moi, c'est ceinture et brettelles, donc désactivation ET "rajoutes des tests dans les fonctions de traitement ", car la prise en compte du changement d'état peut avoir une certaine latence. :aie:

Citation:

---

Envoyé par bacelar

Si mes souvenirs sont bons, c'est plus WM_USER + x mais WM_APP + x dû à de sombres histoires de framework additionnels. :aie:

---

Ha ? Il va falloir que je révise mes sources alors :) mais l'esprit est là.

Citation:

---

Envoyé par ram-0000

Un thread de travail (tes threads 1 et 2) sont probablement des thread de travail ou encore Working Thread ne doit pas modifier l'interface graphique.

Il doit :

• Envoyer un message spécifique à l'interface graphique WM_USER + x (à définir, c'est ton message utilisateur) avec des paramètres wParam et lParam qui permettent à l'interface graphique de savoir ce que veut le working thread. Pour cela, il faut que le working thread connaisse le handle HWND (et pas le CWnd *) de l'interface graphique. En général, c'est passé en paramètre lors de la création du thread.
• Ce message doit être envoyé par SendMessage ou PostMessage (SendMessage est bloquant et attend que le message soit traité par la l'interface graphique, PostMessage ne fait que poster et retourne immédiatement)
• L'interface graphique doit intercepter le message WM_USER + x dans le MESSAGE_MAP et faire le traitement en fonction des différents paramètres reçus (dans wParam et lParam)

---

Bonjour,

Je ne vois pas trop quoi faire du handle HWND. Je reprends mon code seulement aujourd'hui, ai cherché pas mal d'informations sur internet, mais n'ai rien trouvé de concret. La plupart des tutoriels se contentent de montrer comment définir son propre message, comment envoyer un message avec SendMessage() ou GetMessage(). Les exemples choisis ne nécessitent pas de passer des paramètres à la fonction de traitement du message, je n'ai donc pas récolté beaucoup d'informations.

J'ai mon propre message, la fonction associée, d'en-tête :

Code:

---

LRESULT NomFonction(WPARAM wParam, LPARAM lParam)

---

Maintenant, j'imagine que dans mon thread de travail je vais devoir envoyé des messages via :

Code:

---

SendMessage(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)

---

,
de façon à ce que ce handle me serve à quelque chose. Cependant, je ne vois pas du tout comment procéder, notamment par un message utilisateur, et encore moins ce qui doit être mis dans WPARAM et LPARAM. Je veux dire par là, quel(s) type(s) ? Je comptais n'envoyer que des entiers ou des chaînes de caractères (CString). Ensuite, comment identifier la "commande" dans la fonction de traitement du message. Par exemple, comment distinguer une demande de SetStep() d'une demande de StepIt() pour ma barre de progression. Enfin, comment créer et modifier ma barre de progression en utilisant le handle de ma fenêtre d'application ?

Désolé, mais j'ai vraiment pris du temps à chercher ça, sans trouver.

Merci par avance !

:faq::applo:
http://cpp.developpez.com/faq/vc/?pa...PrivateMessage

Citation:

---

Envoyé par bacelar

:faq::applo:
http://cpp.developpez.com/faq/vc/?pa...PrivateMessage

---

Ah :), merci, ça me donnera un deuxième support puisque j'avais déjà imprimé tout ça (...). D'ailleurs, mon problème ne se situait pas vraiment au niveau de la définition de messages utilisateurs, ni même des fonctions associées. Je me demande si tu as lu :cry:.

Plus sérieusement, savoir comment définir ses propres messages et les fonctions associées est très bien, mais savoir ce qui précède plus la manière d'implémenter les fonctions est plus utile.

Bref, j'ai réglé mon problème. Si jamais quelqu'un venait à rencontrer le même souci que moi, voici un lien utile :
Updating a CProgressCtrl from a multi-threaded application

Merci à vous pour les pistes. ;)

Je pensais qu'il ne te manquait que le mécanisme de routage des messages vers la fonction.
Le lien montre comment faire ce routage.

Qu'est-ce qui te bloquait si ce n'est pas ce routage des messages ?