Re: parade pour ne pas ecrire une Thread - C++ (French)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Re: parade pour ne pas ecrire une Thread

C++Talk.NET Forum Index -> C++ (French)

View previous topic :: View next topic

Author

Message

Pierre Maurette
Guest

Posted: Thu Apr 01, 2004 6:55 am Post subject: Re: parade pour ne pas ecrire une Thread

"Arnaud Debaene" <adebaene (AT) club-internet (DOT) fr> typa:

[...]

Quote:

Le code est normalement saisi (c'est classique) dans des gestionnaires
d'évènement, donc dans le thread de WndProc. Ce que vous nommez "pompe
à messages". J'utilise le terme WndProc pour bien différencier de la
boucle primaire du WinMain.
Tu confonds 2 choses : la "pompe à messages" est la boucle qui vide la file
de messages d'une fenêtre : elle appelle la fonction qui fait le traitement
des messages (WndProc sous Windows).
Moi pas confondre, problème de vocabulaire. J'avais un doute, c'est la

raison pour laquelle j'avais précisé et utilisais le terme WndProc.

Quote:

De manière générique, une pompe à
message pourrait sécrire :

Tantque (msg=prochain_message_dans_la_queue_de_la_fenêtre)
si (msg==MESSAGE_DE_FIN)
sortir_boucle;
preprocesser(msg)
WndProc(msg) //fonction utilisateur qui traite les messages
fintantque
Sous Windows je n'utilise et n'ai jamais vu utiliser que

DispatchMessage (qui amène à WndProc) à ce niveau (obligatoire?). Le
résultat est le même.

Quote:

prochain_message_dans_la_queue_de_la_fenêtre est une fonction bloquante
(GetMessage sous Windows) qui ne retourne que quand un message est
effectivement disponible. C'est ce qui fait qu'un thread GUI ne consomme
générallement que très peu de CPU.
C'est effectivement un point clé, qui permet de garder ouverts un

grand nombre d'applis sans préjudice (conjointement à la mémoire
virtuelle).

[...]

Quote:

Je dispose également de la méthode ProcessMessages. Elle demande à
Windows de traiter tous les messages en attente, et non uniquement
ceux de l'appli.
Non : elle créé une pompe à message locale qui vide la queue de messages de
la fenêtre au moment de son appel. Elle est équivalente à :
tantque (file_message_non_vide)
msg=msg=prochain_message_dans_la_queue_de_la_fenêtre
preprocesser(msg)
WndProc(msg) //fonction utilisateur qui traite les messages
fintantque

Cette fonction est très efficace, il semble qu'elle retourne
très rapidement en cas d'absence de message à traiter.
Bien sûr : dans ce cas elle se contente de constater que la file de messages
est vide et retourne. Pourquoi devrait-elle être longue?

C'est là que
vient ma question: contrairement à ce que je pensais, ce n'est pas un
simple "wrapper" d'une fonction Windows.
Et si! PeekMessage / GetMessage et consort! Borland ne fournit pas le code
source de la VCL pour pouvoir examiner ces détails?
Je crains que non (la CLX peut-être, avec Kylix Open-source). Mais

c'est très facile à tracer. J'avais bien vu une boucle de
PeekMessageA/TranslateMessage/DispatchMessageA. Mais quelque chose me
chagrinait: si je fais un thread et lui affecte une priorité
TimeCritical, avec ce stupide code:
while(!Terminated)
{
//Application->ProcessMessages();
}
Tout est bloqué, même le Ctrl-Alt-Suppr. Ajouter ProcessMessages
débloque la situation. Maintenant, je comprends (je suppose, en fait)
que le fait de rendre la main à Windows fait que celui-ci la donne aux
autres applis. Je vais le coder, je verrai bien.

Quote:

Auriez-vous une idée d'une
façon simple d'écrire ce truc-là, uniquement en API Windows?
Oui, mais là on vire carrément HS. Voire sur un groupe consacré à Windows.
Je le code dès que j'ai un moment, et en cas de problème, je poste

sur:
fr.comp.os.ms-windows.programmation

Quote:

Je me sers de cette fonction pour résoudre le problème du calcul
bloquant. En fait, le plus souvent, j'ouvre une fiche spécifique,
modale ou non modale selon le contexte, contenant une indication de
progression, une bouton "Cancel", et que sais-je. Ça a un goût de
thread d'interface, mais ce n'en est bien entendu pas un.
Une règle fondamentale de la programmation GUI, c'est qu'il ne doit y avoir
qu'un seul thread qui vide la queue de messages d'une fenêtre donnée. Sinon,
lorque tu reçois une série de messages qui doivent être traités dans un
ordre spécifique, l'un après l'autre, pour avoir un sens (genre le message
"clic_souris_down" suivi de "clic_souris_up"), ils risquent d'être retirés
de la queue par des threads différents, et tu ne pourras plus les traiter
correctement. Ton design est fragile.
Oui, bwana. OK pour l'idée générale. Mais dans ce cas, je suis dans le

thread principal. Si je devais utiliser ProcessMessages dans un thread
enfant (peu probable), il suffit d'utiliser la méthode Synchronize
(Borlanderie) du thread pour que ProcessMessages s'exécute dans le
thread principal.

[...]

Quote:

La charge d'un tel thread dépend de la
priorité qui lui est affectée, de celle de process propriétaire, des
droits de la session (oui ?),
Non.
Effectivement Wink

Quote:

Autant traiter les problèmes
de messsages par des solutions "messages", et réserver les threads
multiples à des problématiques spécifiques.
Le problème de l'approche "messages", c'est que le code de
l'algortihmie se retrouve mélangé avec du code de gestion d'IHM, ce
qui n'est jamais très propre ni très maintenable.
Pas sous Builder, puisqu'on ne se proccupe pas vraiment de l'IHM (une
fois conçue).
Si : tu as des appels à "ProcessMessages" dispersés au milieu de ton algo de
traitement, alors qu'ils n'ont rien à y faire. Qui plus est, selon la
puissance de la machine, si elle est plus ou moins chargée, etc... il faut
mettre plus ou moins de "ProcessMessages" au milieu de tes calculs pour
garder un GUI fluide : bref c'est du bricolage.
OK pour le bricolage, c'était déjà dans ma culotte (commence à être

garnie, la culotte, n'abusez pas). Dans le cas qui nous préoccupe en
tous cas, puisqu'il existe des utilisations pertinentes de
ProcessMessages.

Il me semble que l'on prend peu de risques si, sur un problème donné,
on utilise les possibilités de son EDI (s'il est de qualité) en bon
père de famille, conformément aux parties "Guide du développeur" de la
documentation par exemple, en utilisant exclusivement les ressources
de l'EDI sur le sujet. On peut également choisir d'utiliser les API de
l'OS. Là où ça craint, c'est quand on mélange les deux, sur un
problème donné (et non pas au niveau de l'ensemble de l'application).

Pierre

kanze@gabi-soft.fr
Guest

Posted: Thu Apr 01, 2004 8:01 am Post subject: Re: parade pour ne pas ecrire une Thread

"Michel Michaud" <mm (AT) gdzid (DOT) com> wrote

Quote:

Dans news:d6652001.0403310713.7866b00 (AT) posting (DOT) google.com,
[email]kanze (AT) gabi-soft (DOT) fr[/email] <kanze (AT) gabi-soft (DOT) fr> a écrit :
Jean-Marc Bourguet <jm (AT) bourguet (DOT) org> wrote in message
news:<pxbzn9yibqi.fsf (AT) news (DOT) bourguet.org>...
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes:
L'utilisation de plusieurs processus c'est un peu perdu
dernièrement. C'est dommage ; quand la quantité de données n'est
pas grande, et le calcul prend du temps, c'est parfois une bonne
solution.

Je suis d'accord et aussi c'est beaucoup plus facile a ajouter
apres coup dans une application non concue pour quand la methode
est utilisable. Mais ce n'est pas notre cas.

Comme j'ai dit, c'est PARFOIS une bonne solution. Je ne disais pas
qu'il faut s'en servir partout, seulement que c'était peut-être pas
très bien qu'on ne s'en sert plus jamais.

C'est intéressant. J'enseigne encore ça. Devrais-je parler plus de
threads ? Je ne sais pas, mais justement, je trouve plus facile de
faire les choses « correctement » avec plusieurs processus...

C'est très bien. Comme tu dis, c'est en général plus facile à faire
propre comme ça. En revanche, la communication entre processus est
souvent plus lourde et plus complexe que la communication entre threads.
Il n'y a pas de meilleur solution dans l'absolue.

En revanche, même si toi, tu l'enseignes... Il y a des modes en
informatique ; actuellement, la mode semble être des threads et des DLL.
Du coup, on les trouve partout, qu'il y en a besoin ou non. Il y a des
cas où l'application a besoin des threads, de même qu'il y a des cas où
il faut un chargement dynamique. Dans ces cas-là, on s'en sert. Dans les
autres, il vaut mieux les éviter -- ils deviennent des complications
pour rien.

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr
Guest

Posted: Thu Apr 01, 2004 8:01 am Post subject: Re: parade pour ne pas ecrire une Thread

"Michel Michaud" <mm (AT) gdzid (DOT) com> wrote

Quote:

hetman
Guest

Posted: Fri Apr 02, 2004 2:17 am Post subject: Re: parade pour ne pas ecrire une Thread

Quote:

et c quoi l'automate de traitement, ça veut dire quoi?

Vu lla longueur du fil ce n'est pas une appli toute bête et d'ailleurs
une appli toute bête se remplace par un crayon et des feuilles de papier.

Ce serait trop long d'expliquer la notion d'automate mais jez te
recommande vivement de spécifier ton appli avec le langage esterel
http://www-sop.inria.fr/meije/esterel/esterel-eng.html. Tu compiles et tu
obtiens du c. Esterel est spécialement étudié pour les systèmes
synchrones. Il construit automatiquement un automate à partir de la
spécification écrite en esterel et produit un source en c

Michel Michaud
Guest

Posted: Fri Apr 02, 2004 6:34 am Post subject: Re: parade pour ne pas ecrire une Thread

Dans news:d6652001.0403312327.30fb09a2 (AT) posting (DOT) google.com,
[email]kanze (AT) gabi-soft (DOT) fr[/email] <kanze (AT) gabi-soft (DOT) fr> a écrit :

Quote:

"Michel Michaud" <mm (AT) gdzid (DOT) com> wrote in message
news:<2eHac.57962$1A6.1330880 (AT) news20 (DOT) bellglobal.com>...
C'est intéressant. J'enseigne encore ça. Devrais-je parler plus de
threads ? Je ne sais pas, mais justement, je trouve plus facile de
faire les choses « correctement » avec plusieurs processus...

C'est très bien. Comme tu dis, c'est en général plus facile à faire
propre comme ça. En revanche, la communication entre processus est

Pas seulement « propre », correcte aussi. En général, les primitives
de communication interprocessus des systèmes d'exploitation modernes
sont à l'abri des problèmes d'accès concurrents et de synchronisation
dont on doit se préoccuper avec les threads pour à peu près tout.

Quote:

souvent plus lourde et plus complexe que la communication entre
threads. Il n'y a pas de meilleur solution dans l'absolue.

Plus complexe ? Je ne sais pas. Certainement si on ne veut pas
penser aux problèmes des accès concurrents, mais sinon ?

Tu as raison de dire qu'il n'y a pas de solution miracle, c'est
pourquoi je parle de communications/synchronisation interprocessus,
pour balancer la publicité faite pour les threads, en Java par
exemple...

Quote:

En revanche, même si toi, tu l'enseignes... Il y a des modes en
informatique ; actuellement, la mode semble être des threads et des
DLL. Du coup, on les trouve partout, qu'il y en a besoin ou non. Il
y a des cas où l'application a besoin des threads, de même qu'il y
a des cas où il faut un chargement dynamique. Dans ces cas-là, on
s'en sert. Dans les autres, il vaut mieux les éviter -- ils
deviennent des complications pour rien.

Peut-être est-ce parce que j'ai surtout de l'expérience réelle
avec les programmes multi-processus (par exemple, parce que j'ai
jadis écrit un spooler d'impression tellement utilisé souvent que
j'ai eu la « chance » de voir et corriger tous les problèmes
possibles et imaginables), mais je trouve que pour les
applications courantes, les threads sont souvent d'application
triviale... ou inutile ! Peut-être est-ce parce que les gens
les évitent lorsqu'ils sentent que ça deviendra compliqué. Je
suis sûr que certaines personnes n'ont pas le choix et les
utilisent même quand ça devient compliqué, mais « ces experts »
ne sortiront probablement pas de mes groupes d'élèves...

--
Michel Michaud [email]mm (AT) gdzid (DOT) com[/email]
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

DINH Viêt Hoà
Guest

Posted: Fri Apr 02, 2004 7:21 am Post subject: Re: parade pour ne pas ecrire une Thread

Michel Michaud wrote :

Quote:

Pour ajouter un commentaire de la part d'un utilisateur de thread,
dans du code réseau par exemple, je préfère pas mal utiliser les threads
plutôt qu'écrire du code basé sur les callbacks. Je trouve les codes
threadés plus lisibles. (Certes, le code sera imbriqué de gestion de
annulations Smile

)

Pour ce qui est du sujet des annulations, je crois qu'en pratique, dans
les programmes de type interface graphiques (ou interface ncurses pour
parler d'expérience plus récente), les annulations se font la main afin
de faire un nettoyage un peu plus propre et donner un acquittement comme
quoi l'annulation a bien été effectuée.

--
DINH V. Hoa,

"un joint tu vas pas avoir ton cerveau détruit à la longue" -- b.

kanze@gabi-soft.fr
Guest

Posted: Mon Apr 05, 2004 6:44 am Post subject: Re: parade pour ne pas ecrire une Thread

"Michel Michaud" <mm (AT) gdzid (DOT) com> wrote

Quote:

Dans news:d6652001.0403312327.30fb09a2 (AT) posting (DOT) google.com,
[email]kanze (AT) gabi-soft (DOT) fr[/email] <kanze (AT) gabi-soft (DOT) fr> a écrit :
"Michel Michaud" <mm (AT) gdzid (DOT) com> wrote in message
news:<2eHac.57962$1A6.1330880 (AT) news20 (DOT) bellglobal.com>...

C'est intéressant. J'enseigne encore ça. Devrais-je parler plus de
threads ? Je ne sais pas, mais justement, je trouve plus facile de
faire les choses « correctement » avec plusieurs processus...

C'est très bien. Comme tu dis, c'est en général plus facile à faire
propre comme ça. En revanche, la communication entre processus est

Pas seulement « propre », correcte aussi. En général, les primitives
de communication interprocessus des systèmes d'exploitation modernes
sont à l'abri des problèmes d'accès concurrents et de synchronisation
dont on doit se préoccuper avec les threads pour à peu près tout.

souvent plus lourde et plus complexe que la communication entre
threads. Il n'y a pas de meilleur solution dans l'absolue.

Plus complexe ? Je ne sais pas. Certainement si on ne veut pas penser
aux problèmes des accès concurrents, mais sinon ?

Tout dépend. La communicatioin entre les processus est typiquement
séquencielle -- si on a des structures de données complexes, il faut les
sérializer. Tandis qu'avec les threads, on passe un pointeur à la
racine, c'est tout.

Quant au problème des accès concurrents, tout dépend aussi. D'après mon
expérience, la plupart du temps (mais pas toujours), si la conception
est bonne, il n'y a pas de problème. Mais tu as raison que même dans ces
cas-là, il faut faire au moins assez d'analyses pour savoir qu'on est
dans ce cas-là, ce qui n'est pas nécessaire quand on traite avec deux
processus.

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr
Guest

Posted: Mon Apr 05, 2004 8:01 am Post subject: Re: parade pour ne pas ecrire une Thread

DINH Viêt Hoà <dinh.viet.hoa (AT) free (DOT) fr> wrote

Quote:

Michel Michaud wrote :

Peut-être est-ce parce que j'ai surtout de l'expérience réelle avec
les programmes multi-processus (par exemple, parce que j'ai jadis
écrit un spooler d'impression tellement utilisé souvent que j'ai eu
la « chance » de voir et corriger tous les problèmes possibles et
imaginables), mais je trouve que pour les applications courantes,
les threads sont souvent d'application triviale... ou inutile !
Peut-être est-ce parce que les gens les évitent lorsqu'ils sentent
que ça deviendra compliqué. Je suis sûr que certaines personnes
n'ont pas le choix et les utilisent même quand ça devient compliqué,
mais « ces experts » ne sortiront probablement pas de mes groupes
d'élèves...

Pour ajouter un commentaire de la part d'un utilisateur de thread,
dans du code réseau par exemple, je préfère pas mal utiliser les
threads plutôt qu'écrire du code basé sur les callbacks. Je trouve les
codes threadés plus lisibles. (Certes, le code sera imbriqué de
gestion de annulations Smile

)

Tu n'as pas l'air d'avoir suivi la discussion. L'alternatif qu'on
considère, ce n'est pas les callback, c'est d'utiliser un processus à
part. À mon avis, c'est une solution particulièrement intéressant dans
les programmes serveur sur le réseau. (C'est une solution assez
classique sous Unix, où il y a un seul processus, inetd, qui attend des
connections sur une pléthorie de ports, et qui lance chaque fois le
processus qui convient.)

Quote:

Pour ce qui est du sujet des annulations, je crois qu'en pratique,
dans les programmes de type interface graphiques (ou interface ncurses
pour parler d'expérience plus récente), les annulations se font la
main afin de faire un nettoyage un peu plus propre et donner un
acquittement comme quoi l'annulation a bien été effectuée.

Typiquement, dans le cas des logiciels interactifs, c'est le processus
de l'interface qui fait la décision de s'arrêter. Il n'a donc pas de
problème à s'arrêter proprement. Le problème alors, c'est comment il
communique son désir de s'arrêter aux autres processus.

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr
Guest

Posted: Mon Apr 05, 2004 8:01 am Post subject: Re: parade pour ne pas ecrire une Thread

DINH Viêt Hoà <dinh.viet.hoa (AT) free (DOT) fr> wrote

Quote:

)

Quote:

Display posts from previous:

	C++Talk.NET Forum Index -> C++ (French)	All times are GMT
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum