Dans un programme C++ en mode console (fonction main) je dois lancer un
timer (SetTimer) et rien d'autre. Mais il ne faut pas que je sorte du main.
Venant du monde VB, je ferais en VB :
bOK = false
hTimer = SetTimer(0, 0, delay, TimerProc)
While(not bOK) if GetInputState Then DoEvents 'pour pas bloquer
KillTimer hTimer
Sachant que c'est la procédure TimerProc qui mettera à true bOK et donc
mettra fin au programme.
En C++ le programme est quasiment le meme, sauf que je ne sais pas
reproduire le comportement de la ligne :
"if GetInputState then DoEvents"
Tout d'abord merci pour votre participation si active. Ensuite, j'aimerais qu'on fasse un point sur cette histoire.
1/ Les attentes actives 1.1/ Les méthodes
- Sleep - WaitForSingleObject
1.2/ Inconvénients Consomme du temps système a ne rien faire.
2/ Les attentes passives 2.1/ Le méthodes (--bah je sais plus du coup--)
2.2/ Avantages On utilise la philopsopie de Windows à savoir un système évènementiel. Autrement dit c'est pas nous le chef !, on dit se dont on a besoin et Windows nous renseignera/servira par envoi d'évènements. J'aime bien l'image du acte/besoin.
Je vous laisse compléter la section 2.1 ainsi que les autres. Je pense que meme si je suis dans un cas simpliste, il faut quand meme faire les choses dans les regles de l'art, sinon je pense que ca peut vite devenir le foutoir !
Voilà, cela pourrait-etre une partie de la FAC ou une petite doc/tuto à mettre dans un site qui as une section de cours (d'ailleurs en connaissez-vous ou l'on pourrait apprendre les regle de l'art ansi que les fautes à ne pas faire?)
PurL
Bonjour et bonne semaine,
Tout d'abord merci pour votre participation si active.
Ensuite, j'aimerais qu'on fasse un point sur cette histoire.
1/ Les attentes actives
1.1/ Les méthodes
- Sleep
- WaitForSingleObject
1.2/ Inconvénients
Consomme du temps système a ne rien faire.
2/ Les attentes passives
2.1/ Le méthodes
(--bah je sais plus du coup--)
2.2/ Avantages
On utilise la philopsopie de Windows à savoir un système évènementiel.
Autrement dit c'est pas nous le chef !, on dit se dont on a besoin et
Windows nous renseignera/servira par envoi d'évènements.
J'aime bien l'image du acte/besoin.
Je vous laisse compléter la section 2.1 ainsi que les autres.
Je pense que meme si je suis dans un cas simpliste, il faut quand meme faire
les choses dans les regles de l'art, sinon je pense que ca peut vite devenir
le foutoir !
Voilà, cela pourrait-etre une partie de la FAC ou une petite doc/tuto à
mettre dans un site qui as une section de cours (d'ailleurs en
connaissez-vous ou l'on pourrait apprendre les regle de l'art ansi que les
fautes à ne pas faire?)
Tout d'abord merci pour votre participation si active. Ensuite, j'aimerais qu'on fasse un point sur cette histoire.
1/ Les attentes actives 1.1/ Les méthodes
- Sleep - WaitForSingleObject
1.2/ Inconvénients Consomme du temps système a ne rien faire.
2/ Les attentes passives 2.1/ Le méthodes (--bah je sais plus du coup--)
2.2/ Avantages On utilise la philopsopie de Windows à savoir un système évènementiel. Autrement dit c'est pas nous le chef !, on dit se dont on a besoin et Windows nous renseignera/servira par envoi d'évènements. J'aime bien l'image du acte/besoin.
Je vous laisse compléter la section 2.1 ainsi que les autres. Je pense que meme si je suis dans un cas simpliste, il faut quand meme faire les choses dans les regles de l'art, sinon je pense que ca peut vite devenir le foutoir !
Voilà, cela pourrait-etre une partie de la FAC ou une petite doc/tuto à mettre dans un site qui as une section de cours (d'ailleurs en connaissez-vous ou l'on pourrait apprendre les regle de l'art ansi que les fautes à ne pas faire?)
PurL
Manuel Leclerc
> 1/ Les attentes actives 1.1/ Les méthodes
- Sleep - WaitForSingleObject
1.2/ Inconvénients Consomme du temps système a ne rien faire.
Je crois que tu fais une petite confusion. Une attente active est véritablement un truc horrible du genre boucle infinie, sans temporisations. Un peu comme si tu essayais d'ouvrir un fichier et que tu recommences "tout de suite" si ça rate. Ce genre de boucle peut "marcher", mais ça donne souvent une consommation CPU qui monte à 100%.
GetMessage, Sleep et WaitFor sont des attentes passives : tu passes la main à l'OS, la CPU va être utilisée à faire autre chose. Quand ton attente se termine, tu es "réveillé".
A noter pour le fun que pour des raisons de performances on peut parfois préférer faire une attente active très courte, par exemple quand on veut acquérir une ressource à exclusion mutuelle (plus efficace d'essayer quelques micro-secondes d'avoir la ressources en essayant "sans arrêt" que de faire un appel système). Il me semble que les "sections critiques" sont implémentées comme ça. Quand la "micro" attente active échoue, on bascule en mode attente passive avec appel système. Ce genre de technique est à réserver à du code de science-fiction. Le programmeur normal n'en a pas besoin, à mon avis, mais bon.
> 1/ Les attentes actives
1.1/ Les méthodes
- Sleep
- WaitForSingleObject
1.2/ Inconvénients
Consomme du temps système a ne rien faire.
Je crois que tu fais une petite confusion. Une
attente active est véritablement un truc horrible
du genre boucle infinie, sans temporisations.
Un peu comme si tu essayais d'ouvrir un fichier et
que tu recommences "tout de suite" si ça rate.
Ce genre de boucle peut "marcher", mais ça donne
souvent une consommation CPU qui monte à 100%.
GetMessage, Sleep et WaitFor sont des attentes passives : tu
passes la main à l'OS, la CPU va être utilisée à faire autre
chose. Quand ton attente se termine, tu es "réveillé".
A noter pour le fun que pour des raisons de performances on
peut parfois préférer faire une attente active très courte,
par exemple quand on veut acquérir une ressource à exclusion
mutuelle (plus efficace d'essayer quelques micro-secondes
d'avoir la ressources en essayant "sans arrêt" que de
faire un appel système). Il me semble que les "sections
critiques" sont implémentées comme ça. Quand la "micro"
attente active échoue, on bascule en mode attente passive
avec appel système. Ce genre de technique est à réserver à
du code de science-fiction. Le programmeur normal n'en a pas
besoin, à mon avis, mais bon.
1.2/ Inconvénients Consomme du temps système a ne rien faire.
Je crois que tu fais une petite confusion. Une attente active est véritablement un truc horrible du genre boucle infinie, sans temporisations. Un peu comme si tu essayais d'ouvrir un fichier et que tu recommences "tout de suite" si ça rate. Ce genre de boucle peut "marcher", mais ça donne souvent une consommation CPU qui monte à 100%.
GetMessage, Sleep et WaitFor sont des attentes passives : tu passes la main à l'OS, la CPU va être utilisée à faire autre chose. Quand ton attente se termine, tu es "réveillé".
A noter pour le fun que pour des raisons de performances on peut parfois préférer faire une attente active très courte, par exemple quand on veut acquérir une ressource à exclusion mutuelle (plus efficace d'essayer quelques micro-secondes d'avoir la ressources en essayant "sans arrêt" que de faire un appel système). Il me semble que les "sections critiques" sont implémentées comme ça. Quand la "micro" attente active échoue, on bascule en mode attente passive avec appel système. Ce genre de technique est à réserver à du code de science-fiction. Le programmeur normal n'en a pas besoin, à mon avis, mais bon.
Ambassadeur Kosh
> Ensuite, j'aimerais qu'on fasse un point sur cette histoire. 1/ Les attentes actives 1.1/ Les méthodes - Sleep
Sleep sert à dire à ton process "laisse faire les autres pendant au moins X unites de temps". donc, en fait, pendant ce temps, le process ne travaille pas. mais globalement, si on se reveille régulierement pour verifier un état particulier, c'est de l'attente active. plus on augmente X, plus on diminue le temps consacré à la scrutation, mais plus on allonge le temps entre l'evenement et son traitement. l'attente active conduit a cette "dualité" entre temps bouffé pour ne rien faire et reactivité. (suffit de tracer une droite avec un point Evenement et de faire glisser dessus une echelle d'intervalles X et de calculer la moyenne et le pire cas)
et pour conclure : on augmente sa reactivité personnelle au détrimant de la réactivité des autres. applique la regle à chacun...
pour faire une métaphore trollesque à deux balles : un systeme est un ensemble cohérent et unique. l'attente active, c'est un individu égotique qui tire la couverture à lui. dans un systeme ou les individus sont nombreux, la consience de l'autre permet une gestion meilleure des resources. et comme les processus n'ont pas l'omniscience, tout ce qui necessite une vision globale des choses est l'objet d'un superviseur qui decide de qui avance a un moment precis : le systeme.
- WaitForSingleObject
sert à attendre un evenement systeme. elle a donc pour vocation l'attente "passive". mais, comme on l'a vu, on peut utiliser WaitForSingleObject() pour implanter Sleep(). donc, je ne pense pas qu'on puisse ranger WaitForSingleObject dans une seule des categories.
1.2/ Inconvénients Consomme du temps système a ne rien faire.
certes.
et déclenche le traitement trop tard par rapport à l'instant ou l'evenement s'est "reellement produit. dans ton cas, ça n'a pas grande importance, mais imagine que des données arrivent sur un cable. l'emetteur envoie en continu sans attendre de réponse de ta part pour vérifier que tu as bien lu. et bien tu vas lire des données, et certaines vont être ecrasées par les suivantes. donc technique non fiable. je prend un cas particulier, mais imagine que tu mettes un Timer pour repeindre tes fenetres au lieu de travailler avec un WM_PAINT. degueulasse hein ?
2/ Les attentes passives 2.1/ Le méthodes (--bah je sais plus du coup--)
les fonctions et objets systemes qui presentent les "bonnes" propriétés.
par exemple, que se passe t'il quand tu lis un caractere dans un fichier. il y a un laps de temps entre le moment ou tu demandes file >> ch ; et le moment ou ça se produit. et pendant cette eternité (une resource est longue a acceder par rapport à un registre), le processeur pourrais bosser. et c'est ce qu'il fait grace à cette technique. bien sur, il suffirait de dormir exactement le temps qu'il faut avec Sleep pour avoir le même effet, mais en fait, tu n'aurais pas le même effet (imagines toi sur une machine qui bosse pour de vrai avec des traitements en calcul lourd, des requetes à un SGBD plein pot, du Opengl pour la representation etc etc...).
- au moment du reveil, tu ne seras pas prioritaire. ben oui gugus qui demande à lire une donnée sur le port serie et plus pressé qu'un gugus qui sort du lit avec pour seul motif qu'il avait someil.
2) on est incapable dans la majeure partie des cas de calculer le X qu'il faut filer à Sleep. on peut parfois fournir une majoration qui sera toujours monstrueusement. grossiere donc inadequate.
on pourrait resumer tout ça par : "les interruptions, c'est pas fait pour les chiens."
2.2/ Avantages On utilise la philopsopie de Windows à savoir un système évènementiel. Autrement dit c'est pas nous le chef !, on dit se dont on a besoin et Windows nous renseignera/servira par envoi d'évènements. J'aime bien l'image du acte/besoin.
change Windows par systeme multitache prehemptif. c'est le début du parallelisme tout ça.
Je vous laisse compléter la section 2.1 ainsi que les autres. Je pense que meme si je suis dans un cas simpliste, il faut quand meme faire les choses dans les regles de l'art, sinon je pense que ca peut vite devenir le foutoir !
clair.
Voilà, cela pourrait-etre une partie de la FAC ou une petite doc/tuto à mettre dans un site qui as une section de cours (d'ailleurs en connaissez-vous ou l'on pourrait apprendre les regle de l'art ansi que les fautes à ne pas faire?)
labsus :) c'est en FAC qu'on enseigne ça. cours de systeme pour être précis.
pour résumer : - Sleep dans ton cas precis c'est pas la mort. - en .Net, le FileSystemWatcher c'est l'evenement adapté. - sous Windows, je sais plus, mais il y'a ce qu'il faut - en MFC je sais pas si il y'a une class. peut être - faire de l'attente active c'est naze. toujours. (user, driver, ou noyau) - la vraie difficulté du truc, c'est trouver dans l'aide les concepts et l'API qui vont bien.
voila voila. j'espere que ça t'a pas trop gavé.
> Ensuite, j'aimerais qu'on fasse un point sur cette histoire.
1/ Les attentes actives
1.1/ Les méthodes
- Sleep
Sleep sert à dire à ton process "laisse faire les autres pendant au moins X
unites de temps". donc, en fait, pendant ce temps, le process ne travaille
pas. mais globalement, si on se reveille régulierement pour verifier un état
particulier, c'est de l'attente active. plus on augmente X, plus on diminue
le temps consacré à la scrutation, mais plus on allonge le temps entre
l'evenement et son traitement. l'attente active conduit a cette "dualité"
entre temps bouffé pour ne rien faire et reactivité. (suffit de tracer une
droite avec un point Evenement et de faire glisser dessus une echelle
d'intervalles X et de calculer la moyenne et le pire cas)
et pour conclure : on augmente sa reactivité personnelle au détrimant de la
réactivité des autres. applique la regle à chacun...
pour faire une métaphore trollesque à deux balles : un systeme est un
ensemble cohérent et unique. l'attente active, c'est un individu égotique
qui tire la couverture à lui. dans un systeme ou les individus sont
nombreux,
la consience de l'autre permet une gestion meilleure des resources. et
comme les processus n'ont pas l'omniscience, tout ce qui necessite une
vision globale des choses est l'objet d'un superviseur qui decide de qui
avance a un moment precis : le systeme.
- WaitForSingleObject
sert à attendre un evenement systeme. elle a donc pour vocation l'attente
"passive". mais, comme on l'a vu, on peut utiliser WaitForSingleObject()
pour
implanter Sleep(). donc, je ne pense pas qu'on puisse ranger
WaitForSingleObject dans une seule des categories.
1.2/ Inconvénients
Consomme du temps système a ne rien faire.
certes.
et déclenche le traitement trop tard par rapport à l'instant ou l'evenement
s'est "reellement produit. dans ton cas, ça n'a pas grande importance, mais
imagine que des données arrivent sur un cable. l'emetteur envoie en continu
sans attendre de réponse de ta part pour vérifier que tu as bien lu. et bien
tu vas lire des données, et certaines vont être ecrasées par les suivantes.
donc technique non fiable. je prend un cas particulier, mais imagine que
tu mettes un Timer pour repeindre tes fenetres au lieu de travailler avec
un WM_PAINT. degueulasse hein ?
2/ Les attentes passives
2.1/ Le méthodes
(--bah je sais plus du coup--)
les fonctions et objets systemes qui presentent les "bonnes" propriétés.
par exemple, que se passe t'il quand tu lis un caractere dans un fichier. il
y a un laps de temps entre le moment ou tu demandes file >> ch ; et le
moment ou ça se produit. et pendant cette eternité (une resource est longue
a
acceder par rapport à un registre), le processeur pourrais bosser. et c'est
ce qu'il fait grace à cette technique. bien sur, il suffirait de dormir
exactement
le temps qu'il faut avec Sleep pour avoir le même effet, mais en fait, tu
n'aurais
pas le même effet (imagines toi sur une machine qui bosse pour de vrai avec
des traitements en calcul lourd, des requetes à un SGBD plein pot, du Opengl
pour la representation etc etc...).
- au moment du reveil, tu ne seras pas prioritaire. ben oui gugus qui
demande
à lire une donnée sur le port serie et plus pressé qu'un gugus qui sort du
lit
avec pour seul motif qu'il avait someil.
2) on est incapable dans la majeure partie des cas de calculer le X qu'il
faut
filer à Sleep. on peut parfois fournir une majoration qui sera toujours
monstrueusement. grossiere donc inadequate.
on pourrait resumer tout ça par :
"les interruptions, c'est pas fait pour les chiens."
2.2/ Avantages
On utilise la philopsopie de Windows à savoir un système évènementiel.
Autrement dit c'est pas nous le chef !, on dit se dont on a besoin et
Windows nous renseignera/servira par envoi d'évènements.
J'aime bien l'image du acte/besoin.
change Windows par systeme multitache prehemptif. c'est le début du
parallelisme tout ça.
Je vous laisse compléter la section 2.1 ainsi que les autres.
Je pense que meme si je suis dans un cas simpliste, il faut quand meme
faire les choses dans les regles de l'art, sinon je pense que ca peut
vite devenir le foutoir !
clair.
Voilà, cela pourrait-etre une partie de la FAC ou une petite doc/tuto à
mettre dans un site qui as une section de cours (d'ailleurs en
connaissez-vous ou l'on pourrait apprendre les regle de l'art ansi que les
fautes à ne pas faire?)
labsus :)
c'est en FAC qu'on enseigne ça. cours de systeme pour être précis.
pour résumer :
- Sleep dans ton cas precis c'est pas la mort.
- en .Net, le FileSystemWatcher c'est l'evenement adapté.
- sous Windows, je sais plus, mais il y'a ce qu'il faut
- en MFC je sais pas si il y'a une class. peut être
- faire de l'attente active c'est naze. toujours. (user, driver, ou noyau)
- la vraie difficulté du truc, c'est trouver dans l'aide les concepts et
l'API
qui vont bien.
> Ensuite, j'aimerais qu'on fasse un point sur cette histoire. 1/ Les attentes actives 1.1/ Les méthodes - Sleep
Sleep sert à dire à ton process "laisse faire les autres pendant au moins X unites de temps". donc, en fait, pendant ce temps, le process ne travaille pas. mais globalement, si on se reveille régulierement pour verifier un état particulier, c'est de l'attente active. plus on augmente X, plus on diminue le temps consacré à la scrutation, mais plus on allonge le temps entre l'evenement et son traitement. l'attente active conduit a cette "dualité" entre temps bouffé pour ne rien faire et reactivité. (suffit de tracer une droite avec un point Evenement et de faire glisser dessus une echelle d'intervalles X et de calculer la moyenne et le pire cas)
et pour conclure : on augmente sa reactivité personnelle au détrimant de la réactivité des autres. applique la regle à chacun...
pour faire une métaphore trollesque à deux balles : un systeme est un ensemble cohérent et unique. l'attente active, c'est un individu égotique qui tire la couverture à lui. dans un systeme ou les individus sont nombreux, la consience de l'autre permet une gestion meilleure des resources. et comme les processus n'ont pas l'omniscience, tout ce qui necessite une vision globale des choses est l'objet d'un superviseur qui decide de qui avance a un moment precis : le systeme.
- WaitForSingleObject
sert à attendre un evenement systeme. elle a donc pour vocation l'attente "passive". mais, comme on l'a vu, on peut utiliser WaitForSingleObject() pour implanter Sleep(). donc, je ne pense pas qu'on puisse ranger WaitForSingleObject dans une seule des categories.
1.2/ Inconvénients Consomme du temps système a ne rien faire.
certes.
et déclenche le traitement trop tard par rapport à l'instant ou l'evenement s'est "reellement produit. dans ton cas, ça n'a pas grande importance, mais imagine que des données arrivent sur un cable. l'emetteur envoie en continu sans attendre de réponse de ta part pour vérifier que tu as bien lu. et bien tu vas lire des données, et certaines vont être ecrasées par les suivantes. donc technique non fiable. je prend un cas particulier, mais imagine que tu mettes un Timer pour repeindre tes fenetres au lieu de travailler avec un WM_PAINT. degueulasse hein ?
2/ Les attentes passives 2.1/ Le méthodes (--bah je sais plus du coup--)
les fonctions et objets systemes qui presentent les "bonnes" propriétés.
par exemple, que se passe t'il quand tu lis un caractere dans un fichier. il y a un laps de temps entre le moment ou tu demandes file >> ch ; et le moment ou ça se produit. et pendant cette eternité (une resource est longue a acceder par rapport à un registre), le processeur pourrais bosser. et c'est ce qu'il fait grace à cette technique. bien sur, il suffirait de dormir exactement le temps qu'il faut avec Sleep pour avoir le même effet, mais en fait, tu n'aurais pas le même effet (imagines toi sur une machine qui bosse pour de vrai avec des traitements en calcul lourd, des requetes à un SGBD plein pot, du Opengl pour la representation etc etc...).
- au moment du reveil, tu ne seras pas prioritaire. ben oui gugus qui demande à lire une donnée sur le port serie et plus pressé qu'un gugus qui sort du lit avec pour seul motif qu'il avait someil.
2) on est incapable dans la majeure partie des cas de calculer le X qu'il faut filer à Sleep. on peut parfois fournir une majoration qui sera toujours monstrueusement. grossiere donc inadequate.
on pourrait resumer tout ça par : "les interruptions, c'est pas fait pour les chiens."
2.2/ Avantages On utilise la philopsopie de Windows à savoir un système évènementiel. Autrement dit c'est pas nous le chef !, on dit se dont on a besoin et Windows nous renseignera/servira par envoi d'évènements. J'aime bien l'image du acte/besoin.
change Windows par systeme multitache prehemptif. c'est le début du parallelisme tout ça.
Je vous laisse compléter la section 2.1 ainsi que les autres. Je pense que meme si je suis dans un cas simpliste, il faut quand meme faire les choses dans les regles de l'art, sinon je pense que ca peut vite devenir le foutoir !
clair.
Voilà, cela pourrait-etre une partie de la FAC ou une petite doc/tuto à mettre dans un site qui as une section de cours (d'ailleurs en connaissez-vous ou l'on pourrait apprendre les regle de l'art ansi que les fautes à ne pas faire?)
labsus :) c'est en FAC qu'on enseigne ça. cours de systeme pour être précis.
pour résumer : - Sleep dans ton cas precis c'est pas la mort. - en .Net, le FileSystemWatcher c'est l'evenement adapté. - sous Windows, je sais plus, mais il y'a ce qu'il faut - en MFC je sais pas si il y'a une class. peut être - faire de l'attente active c'est naze. toujours. (user, driver, ou noyau) - la vraie difficulté du truc, c'est trouver dans l'aide les concepts et l'API qui vont bien.
