Discussion :

[al2000]

Bonjour,

J'appelle depuis le thread principal une méthode d'un 1er object en fournissant une callback (la méthode fait un traitement synchrone).
Le traitement se termine dans un object de type ContentControl : j'utilise alors le Dispatcher de cet objet pour executer la callback de manière asynchrone via le BeginInvoke.
La callback est effectivement appelée de manière asynchrone.

Par contre, en tracant les thread IDs, je m'apercois que la callback est appelée dans le même thread (thread principal).
Cela me pose problème car je voudrais me synchroniser sur le retour de la callback (en utilisant un ManualResetEventSlim) : si je fait un Wait cela bloque le thead principal.

Comment je peux attendre le retour de la callback sans bloquer le thread ?

[ebastien]

Bonjour,
C'est compliqué de savoir ce que tu veux faire.
BeginInvoke exécutera le Callback dans le thread ayant crée le Control. C'est utile pour mettre à jour le GUI notamment. Il est donc normal qu'il soit exécuté dans le thread principal si le control a été crée dans celui-ci.
Pour répondre au mieux, je pense qu'il faudrait en savoir un peu plus sur ce que fait le Callback et en quoi consiste cette synchronisation.

eb.

[Pol63]

tu peux utiliser un thread classique (system.threading.thread) plutot que de passer par begininvoke
l'appel du callback par callback.invoke sera sur ce thread

[morgand]

Bonjour,

Effectivement dans ce cas ce n'est pas une CallBack que tu veux utiliser mais un EndInvoke.

Le BeginInvoke va appeler dans un autre Thread (Via ThreadPool et je te passe les détails) le traitement voulu, quand tu veux te synchroniser avec ce fameux thread tu dois utiliser EndInvoke, qui va attendre la fin de l'invocation.

Ref: http://msdn.microsoft.com/en-us/library/2e08f6yc.aspx

Je ne sais pas ce que tu veux faire exactement, mais cette façon de faire est à utiliser dans certain cas.

Le BeginInvoke + CallBack est intéressant dans le cas d'un traitement que la GUI a besoin de faire (comme des calculs, ou autres) et que tu ne veux pas bloquer le Thread de la GUI (pour des questions de fluidité). Tu vas donc utiliser un autre Thread pour laisser le Thread de la GUI travailler en paix et la CallBack va tout naturellement retravailler pour mettre à jour la GUI dans le Thread de la GUI, car il va de soit qu'une GUI ne peut être mise à jour uniquement par le Thread de la GUI.

Je ne connais pas ton problème mais l'utilité de faire :

Code :

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

1
2
3
 
monDelegate.BeginInvoke(...,...,);
monDelegate.EndInvoke(....)

c'est 0, autant faire Invoke directement. J'ai déjà vu ça quelque part ... ça servait de cache misère, dans le cas d'un crash sur le thread appelé et bien ça ne crashe pas ton application car l'exécution est dans un Thread non principale.

En C# on peut utiliser de beaucoup de manière les Threads, mais ils n'ont pas fait toutes ces possibilités pour remplir une liste de Feature permettant de faire beau, mais il y a bien une utilité à chaque manière, avec des avantages et des inconvénients. Le plus dur est donc de savoir lequel utilisé et quand

Si tu veux, donne le context et peut être qu'on pourra t’éclairer sur une façon de faire peut être différente (du moins celle que chaque personne pense être la mieux).

[al2000]

Merci pour vos explications.
En fait, je n'avais pas compris que le BeginInvoke de Dispatcher exécute le Callback dans le thread ayant crée le Control...
Par contre, ce que je ne comprend pas, c'est comment le code peut être executé de manière asynchrone tout en restant dans le même thread ?