Discussion :

[zoaax]

Bonjour,

je dois maintenir une application développée par une autre personne que moi.
Dans cette application, un timer exécutée au sein d'un UserControl appelle cycliquement une méthode appelée Lecture.

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
private void Lecture()
{
 If (this.InvokeRequired)
     this.Invoke(new MonDelegate(Lecture));
 else
    Traitement();
}

Ainsi l'appel de la méthode se fait dans le même thread que celui détenant le handle de fenêtre.
Cette méthode fait appel à la méthode Traitement.
Il arrive que le traitement soit plus long que le cycle d'exécution du Timer.
Ainsi, la méthode Lecture sera appelée dans un autre Thread.
Que se passe-t-il dans ce cas lors de l'appel à la méthode Invoke sachant que la méthode Traitement appelée précédemment n'est pas terminée ?

Merci d'avance,
Zoax.

[MABROUKI]

bonjour zaoax
probablement pour ca qu'ils ont mis en place pool thread .Elle sera mise dans le pool de thread de l'application et attendra son tour pour etre excute.
c'est pour ca qu'il y a meme des classes d'evenements(System.Threading.AutoResetEvent) dans System.Thread pour nous informer quand une tache est termine(appel est terminee).
Et savoir ainsi si nous n'avons pas fait d'erreur de logique ,par exemple des boucles infinies,et estimer le temps requis par chaque thread.
regarde sur ce lien http://www.developpez.net/forums/d10...e-mdi-threads/
bon code.........

[Guulh]

Même si les noms de méthode sont les mêmes (Invoke, BeginInvoke, EndInvoke), l'asynchronisme des winforms est différent de celui de la threadpool.
Le point commun dans les deux cas, c'est que Invoke met en queue la méthode passée en paramètre ; mais dans un cas, c'est dans la threadpool, et les différents méthodes Invoke-ées s'exécuteront dans les threads de la pool (tant qu'il y en a), tandis que Control.Invoke met tout dans la même queue, celle du thread créateur du contrôle.

Donc pour répondre à la question initiale : une méthode passée en paramètre de Invoke sera exécutée lorsque le thread d'UI est libre, c'est à dire quasiment tout le temps si l'appli est bien foutue.
Dans le cas ici: est-ce que Traitement est une méthode métier (ie qui va choper des trucs en base, ou fait un gros calcul) comme son nom le laisse supposer ? Parce que si c'est le cas, le code fait le contraire de ce qu'il faut Puisque ce que l'on Invoke, en général, est une méthode qui s'exécute très vite, et qui sert juste à MAJ l'UI avec le résultat d'une méthode métier longue.

Mais en tous cas, là, les Traitement vont s'empiler dans la Queue, si leur durée d'excéution est plus longue que l'intervalle du timer.

[tomlev]

Invoke met en queue la méthode passée en paramètre

[...]

une méthode passée en paramètre de Invoke sera exécutée lorsque le thread d'UI est libre

Ce n'est pas tout à fait exact... Invoke met effectivement la méthode dans la queue, mais ne retourne pas tant qu'elle n'a pas été exécutée. Donc si le thread UI est déjà occupé, ça bloque... (c'est pour ça qu'il ne faut pas appeler Invoke à partir du thread de UI)

Par contre BeginInvoke fait bien ce que tu décris

[Guulh]

Ce n'est pas tout à fait exact... Invoke met effectivement la méthode dans la queue, mais ne retourne pas tant qu'elle n'a pas été exécutée. Donc si le thread UI est déjà occupé, ça bloque... (c'est pour ça qu'il ne faut pas appeler Invoke à partir du thread de UI)

Par contre BeginInvoke fait bien ce que tu décris

Oui, la précision est utile vu le contexte du post initial

Quant à l'appel d'Invoke/BeginInvoke dans le thread de l'UI, j'y avais jamais réfléchi, mais c'est vrai qu'on peut imaginer tout un tas de trucs tordus