Discussion :

[dacid]

Bonjour DonQuiche,

Ouahou, que d'informations... Merci pour ce retour riche... Je n'ai pas encore tout completement absorbé, mais j'ai déjà quelques questions.

1) Invoke: Surprenant, car de nombreux exemples sur la toile m'ont orientés sur cette méthode.
En gros, si 2 Invoke sont fait sur un même controle depuis le même thread, il se bloque sans fin ? Il me semble que dans mon cas, ce sont tous des threads différents... C'est le principe de parallel, non ?

3) Je n'ai pas trop compris... En gros, ca ressemble à un patern observable. Je connais les interfaces, mais je ne vois pas en quoi ça rendrait séquentiel les accès.

Bonjour Pragmateek,
Ca confirme donc que, comme l'avancait DonQuiche, de le lier au parent rend les threads dépendants.
Merci pour ton bout de code, ça fonctionne chez moi.
Mais c'est un peu nébuleux pour moi que d'ajouter une hiérarchie de thread fasse fonctionner le truc.

[DonQuiche]

1) Parallel.Invoke met le thread Ui en attente des ouvriers. Donc pendant ce temps-là la pompe à messages du thread UI ne tourne pas.
Quant à Control.Invoke il place un message dans la file d'attente du thread Ui et attend son traitement. Et pendant ce temps le thread ouvrier est en pause.
L'UI attend le thread ouvrier sans consulter ses messages, le thread ouvrier attend que l'UI réponde à son message.

Ce n'est pas le fait que plusieurs threads veuillent tous consommer l'UI, ce qui ne pose aucun problème. C'est le fait que l'UI est occupée à attendre la fin de ces threads pendant que les threads attendent l'UI. C'est le principe même d'un dead lock: A attend B, B attend A.

Parallel.Invoke est une bonne méthode quand on l'utilise pour ce pour quoi elle est faîte. Elle bloque le thread appelant ce qui est souvent un comportement désirable. Mais c'est problématique si ce thread est celui de l'UI. C'est comme blâmer Int32.Parse de ne pas retourner un double.

3) Le but n'est pas de rendre séquentiel les accès, c'est de forcer la mise en évidence du découplage entre les actions UI, qui doivent être exécutées sur le thread UI, des autres actions exécutées sur le thread d'arrière-plan. La programmation parallèle est difficile, donc il est bon de structurer son code pour mettre en évidence qui fait quoi à quel endroit. Une fois que tu as bien séparé tu peux ensuite trouver des moyens de simplifier, par exemple en initialisant toutes tes barres de progression avant de lancer le moindre thread ouvrier.

[dacid]

Merci à vous deux pour vos réponses rapides et pertinentes.