J'ai besoin d'un timer ultra précis pour effectuer un traitement
d'arrièreplan, et je ne vois pas comment choisir entre un System.Timers.Timer
qui est basé sur les événements, et un System.Threading.Timer qui utilise une
callback et le pool de thread.
Quels sont vraiment les types d'applications pour ces 2 types de timers ?
Dans quel cas utiliser l'un plutôt que l'autre.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gilles TOURREAU [MVP]
Le Fri, 11 Jan 2008 16:47:01 +0100, ShadowFil a écrit:
Bonjour,
J'ai besoin d'un timer ultra précis pour effectuer un traitement d'arrièreplan, et je ne vois pas comment choisir entre un System.Timers.Timer qui est basé sur les événements, et un System.Threading.Timer qui utilise une callback et le pool de thread.
Quels sont vraiment les types d'applications pour ces 2 types de timers ? Dans quel cas utiliser l'un plutôt que l'autre.
Merci pour votre aide.
Bonjour,
Avant de commencer, pouvez-vous expliquer ce que fait exactement votre traitement d'arrière plan ? Car le Timer est a utilisé uniquement dans le cas ou vous souhaitez appeler une procédure tout les x millisecondes...
Cordialement
-- Gilles TOURREAU - MVP C#
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Le Fri, 11 Jan 2008 16:47:01 +0100, ShadowFil
<ShadowFil@discussions.microsoft.com> a écrit:
Bonjour,
J'ai besoin d'un timer ultra précis pour effectuer un traitement
d'arrièreplan, et je ne vois pas comment choisir entre un
System.Timers.Timer
qui est basé sur les événements, et un System.Threading.Timer qui
utilise une
callback et le pool de thread.
Quels sont vraiment les types d'applications pour ces 2 types de timers ?
Dans quel cas utiliser l'un plutôt que l'autre.
Merci pour votre aide.
Bonjour,
Avant de commencer, pouvez-vous expliquer ce que fait exactement votre
traitement d'arrière plan ?
Car le Timer est a utilisé uniquement dans le cas ou vous souhaitez
appeler une procédure tout les x millisecondes...
Le Fri, 11 Jan 2008 16:47:01 +0100, ShadowFil a écrit:
Bonjour,
J'ai besoin d'un timer ultra précis pour effectuer un traitement d'arrièreplan, et je ne vois pas comment choisir entre un System.Timers.Timer qui est basé sur les événements, et un System.Threading.Timer qui utilise une callback et le pool de thread.
Quels sont vraiment les types d'applications pour ces 2 types de timers ? Dans quel cas utiliser l'un plutôt que l'autre.
Merci pour votre aide.
Bonjour,
Avant de commencer, pouvez-vous expliquer ce que fait exactement votre traitement d'arrière plan ? Car le Timer est a utilisé uniquement dans le cas ou vous souhaitez appeler une procédure tout les x millisecondes...
Cordialement
-- Gilles TOURREAU - MVP C#
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Ambassadeur kosh
ok, pas le timer des winforms qui est un peu foufou. entre les deux autres, le principe est le même, hormis l'interface qui offre des fonctionalités différentes. si vous voulez un truc precis, mais genre comme le System.Decimal l'est par rapport à un System.Double, il va falloir pondre un peu de code, parceque vous remarquerez que quand vous demandez d'etre reveillé au bout d'une seconde, il y'a un dt pas si négligeable que ça qui vient s'ajouter. donc pour faire des choses régulierement toutes les secondes, et tomber pile sur l'heure de votre montre, va falloir travailler un peu.
si ça vous interesse, je peux vous filer ce code.
Gilles à raison, sans plus de précision, c'est difficile de répondre précisement. et ce n'est même pas dit qu'un timer soit la bonne solution à votre probleme...
Cordialement,
Frédéric DIDIER
ok, pas le timer des winforms qui est un peu foufou.
entre les deux autres, le principe est le même, hormis l'interface qui offre
des fonctionalités différentes.
si vous voulez un truc precis, mais genre comme le System.Decimal l'est par
rapport à un System.Double, il va falloir pondre un peu de code, parceque
vous remarquerez que quand vous demandez d'etre reveillé au bout d'une
seconde, il y'a un dt pas si négligeable que ça qui vient s'ajouter. donc
pour faire des choses régulierement toutes les secondes, et tomber pile sur
l'heure de votre montre, va falloir travailler un peu.
si ça vous interesse, je peux vous filer ce code.
Gilles à raison, sans plus de précision, c'est difficile de répondre
précisement. et ce n'est même pas dit qu'un timer soit la bonne solution à
votre probleme...
ok, pas le timer des winforms qui est un peu foufou. entre les deux autres, le principe est le même, hormis l'interface qui offre des fonctionalités différentes. si vous voulez un truc precis, mais genre comme le System.Decimal l'est par rapport à un System.Double, il va falloir pondre un peu de code, parceque vous remarquerez que quand vous demandez d'etre reveillé au bout d'une seconde, il y'a un dt pas si négligeable que ça qui vient s'ajouter. donc pour faire des choses régulierement toutes les secondes, et tomber pile sur l'heure de votre montre, va falloir travailler un peu.
si ça vous interesse, je peux vous filer ce code.
Gilles à raison, sans plus de précision, c'est difficile de répondre précisement. et ce n'est même pas dit qu'un timer soit la bonne solution à votre probleme...
Cordialement,
Frédéric DIDIER
Delf
Ambassadeur kosh a écrit :
entre les deux autres, le principe est le même, hormis l'interface qui offre des fonctionalités différentes.
Ya pas une différence entre un timer qui déclenche une action à T fixé et un thread qui utiliserait un sleep() auquel faut ajouter le temps du dernier traitement ?
-- Delf
Ambassadeur kosh a écrit :
entre les deux autres, le principe est le même, hormis l'interface qui offre
des fonctionalités différentes.
Ya pas une différence entre un timer qui déclenche une action à T fixé
et un thread qui utiliserait un sleep() auquel faut ajouter le temps du
dernier traitement ?
entre les deux autres, le principe est le même, hormis l'interface qui offre des fonctionalités différentes.
Ya pas une différence entre un timer qui déclenche une action à T fixé et un thread qui utiliserait un sleep() auquel faut ajouter le temps du dernier traitement ?
-- Delf
Gloops
Delf a écrit, le 19/01/2008 00:27 :
Ambassadeur kosh a écrit :
entre les deux autres, le principe est le même, hormis l'interface q ui offre des fonctionalités différentes.
Ya pas une différence entre un timer qui déclenche une action à T fixé et un thread qui utiliserait un sleep() auquel faut ajouter le temps du dernier traitement ?
Bonsoir,
Là je crois que je peux prendre le risque de répondre, même si c'es t en transposant des trucs vus en VBA (mais on en a déjà parlé ici je cr ois ?).
Sleep, si ça correspond à l'API du même nom, entraîne une tempori sation en gardant le contrôle de la machine, donc empêchera les autres threa ds de faire ce qu'ils ont à faire, inconvénient que n'ont pas les timers . Est-ce qu'on a un temps précis avec ? Mais ça supposerait de calculer le temps restant à courir après la fin du traitement précédent -en f ait, après le cumul du traitement précédent et de l'exécution d'un DoE vents qui rend le contrôle aux autres threads. En échaffaudant, est-ce que je me suis cassé la figure ?
Delf a écrit, le 19/01/2008 00:27 :
Ambassadeur kosh a écrit :
entre les deux autres, le principe est le même, hormis l'interface q ui
offre des fonctionalités différentes.
Ya pas une différence entre un timer qui déclenche une action à T fixé
et un thread qui utiliserait un sleep() auquel faut ajouter le temps du
dernier traitement ?
Bonsoir,
Là je crois que je peux prendre le risque de répondre, même si c'es t en
transposant des trucs vus en VBA (mais on en a déjà parlé ici je cr ois ?).
Sleep, si ça correspond à l'API du même nom, entraîne une tempori sation
en gardant le contrôle de la machine, donc empêchera les autres threa ds
de faire ce qu'ils ont à faire, inconvénient que n'ont pas les timers .
Est-ce qu'on a un temps précis avec ? Mais ça supposerait de calculer le
temps restant à courir après la fin du traitement précédent -en f ait,
après le cumul du traitement précédent et de l'exécution d'un DoE vents
qui rend le contrôle aux autres threads. En échaffaudant, est-ce que je
me suis cassé la figure ?
entre les deux autres, le principe est le même, hormis l'interface q ui offre des fonctionalités différentes.
Ya pas une différence entre un timer qui déclenche une action à T fixé et un thread qui utiliserait un sleep() auquel faut ajouter le temps du dernier traitement ?
Bonsoir,
Là je crois que je peux prendre le risque de répondre, même si c'es t en transposant des trucs vus en VBA (mais on en a déjà parlé ici je cr ois ?).
Sleep, si ça correspond à l'API du même nom, entraîne une tempori sation en gardant le contrôle de la machine, donc empêchera les autres threa ds de faire ce qu'ils ont à faire, inconvénient que n'ont pas les timers . Est-ce qu'on a un temps précis avec ? Mais ça supposerait de calculer le temps restant à courir après la fin du traitement précédent -en f ait, après le cumul du traitement précédent et de l'exécution d'un DoE vents qui rend le contrôle aux autres threads. En échaffaudant, est-ce que je me suis cassé la figure ?
Gilles TOURREAU [MVP]
> Bonsoir,
Là je crois que je peux prendre le risque de répondre, même si c'est en transposant des trucs vus en VBA (mais on en a déjà parlé ici je crois ?).
Sleep, si ça correspond à l'API du même nom, entraîne une temporisation en gardant le contrôle de la machine, donc empêchera les autres threads de faire ce qu'ils ont à faire, inconvénient que n'ont pas les timers. Est-ce qu'on a un temps précis avec ? Mais ça supposerait de calculer le temps restant à courir après la fin du traitement précédent -en fait, après le cumul du traitement précédent et de l'exécution d'un DoEvents qui rend le contrôle aux autres threads. En échaffaudant, est-ce que je me suis cassé la figure ?
Bonjour,
Non, la méthode/fonction Sleep dans .NET/Windows, met le thread en cours d'execution en pause uniquement ! (Et ne bloque en aucun cas les autres Threads...). A mon gout, c'est un peu usine à gaz le fait d'utiliser un thread avec un sleep au lieu d'un timer, si l'on souhaite déclencher une procédure toutes les n millisecondes...
Cependant, il faudrait que l'auteur du premier post puisse nous en dire plus sur son problème...
Cordialement
-- Gilles TOURREAU - MVP C#
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
> Bonsoir,
Là je crois que je peux prendre le risque de répondre, même si c'est en
transposant des trucs vus en VBA (mais on en a déjà parlé ici je crois ?).
Sleep, si ça correspond à l'API du même nom, entraîne une temporisation en
gardant le contrôle de la machine, donc empêchera les autres threads de
faire ce qu'ils ont à faire, inconvénient que n'ont pas les timers. Est-ce
qu'on a un temps précis avec ? Mais ça supposerait de calculer le temps
restant à courir après la fin du traitement précédent -en fait, après le
cumul du traitement précédent et de l'exécution d'un DoEvents qui rend le
contrôle aux autres threads. En échaffaudant, est-ce que je me suis cassé
la figure ?
Bonjour,
Non, la méthode/fonction Sleep dans .NET/Windows, met le thread en cours
d'execution en pause uniquement ! (Et ne bloque en aucun cas les autres
Threads...).
A mon gout, c'est un peu usine à gaz le fait d'utiliser un thread avec un
sleep au lieu d'un timer, si l'on souhaite déclencher une procédure toutes
les n millisecondes...
Cependant, il faudrait que l'auteur du premier post puisse nous en dire plus
sur son problème...
Là je crois que je peux prendre le risque de répondre, même si c'est en transposant des trucs vus en VBA (mais on en a déjà parlé ici je crois ?).
Sleep, si ça correspond à l'API du même nom, entraîne une temporisation en gardant le contrôle de la machine, donc empêchera les autres threads de faire ce qu'ils ont à faire, inconvénient que n'ont pas les timers. Est-ce qu'on a un temps précis avec ? Mais ça supposerait de calculer le temps restant à courir après la fin du traitement précédent -en fait, après le cumul du traitement précédent et de l'exécution d'un DoEvents qui rend le contrôle aux autres threads. En échaffaudant, est-ce que je me suis cassé la figure ?
Bonjour,
Non, la méthode/fonction Sleep dans .NET/Windows, met le thread en cours d'execution en pause uniquement ! (Et ne bloque en aucun cas les autres Threads...). A mon gout, c'est un peu usine à gaz le fait d'utiliser un thread avec un sleep au lieu d'un timer, si l'on souhaite déclencher une procédure toutes les n millisecondes...
Cependant, il faudrait que l'auteur du premier post puisse nous en dire plus sur son problème...
Cordialement
-- Gilles TOURREAU - MVP C#
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr