Bonjour,
 
Je viens vers vous pour avoir des conseils sur l'utilisation des tâches en C#.
 
Dans une appli où je dois faire du traitement de masse, j'ai une datagrid avec en première colonne une icône qui indique quel élément est en cours de traitement.  
 
Le mode opératoire souhaité est le suivant :

• Ma première ligne est traitée, mon icône prend la forme d'un gif animé de chargement,
• J'appelle ma tâche pour traiter mon enregistrement sans figer l'écran,
• Selon le résultat, la tâche doit mettre à jour la ligne (icône qui prend une forme différente selon le succès ou l'échec de la tâche),
• Passage à la ligne suivante.

Je fais donc une boucle pour parcourir mon datagrid :
 

 
Et dans ma tâche, j'ai le code suivant :  
 

 
En opérant comme ça j'ai plusieurs problèmes :

• Les tâches ne s'exécutent pas les unes après les autres (je comprends pourquoi même si ça m'embête),
• mon "rowIndex" dans ma tâche matache() se retrouve parfois avec une valeur hors limite car, de ce que je comprends, même si ma tâche est lancée, mon rowIndex continue à évoluer dans la boucle for()

Que feriez-vous à ma place ? Quelles sont vos façons d'opérer ?
 
Si vous avez des liens d'exemple ou du code dont je pourrais m'inspirer afin de maitriser ce système de tâche, ça me serait d'une grande aide !
 
Merci pour vos retours

Tu veux que ça soit parallèle ou juste asynchrone (non bloquant pour l'UI) ?
Parce que la y a rien pour limiter le parallélisme, ça doit être un gros carnage sur une grille bien remplie.
 
Ton énoncé n'est pas très logique, tu parles de tâches qui doivent s'exécuter dans l'ordre mais à côté de ça tu balances un truc massivement parallèle.

C'est bien pour ça que je viens demander conseil figure toi    
 
Si tu relis bien mon énoncé, je parle bien du fait que les tâches doivent s'exécuter dans l'ordre. Si je "balances un truc massivement parellele" c'est parce que c'est quelque chose de nouveau pour moi et que je ne maitrise pas. Mais on part tous de 0 un jour, alors je ne demande qu'à apprendre    

Tu peux partager un exemple complet ?
Et là j'essaierai de te l'adapter .
I'll y a des trucs pour limiter le nombre de threads déjà, ça sera moins chaotique.
Et j'ai beau relire, je trouve que tu ne réponds pas complètement à la question, justement parce que ce que tu fais dans le code n'est pas d'accord avec ce que tu écris, donc il faut bien demander à quoi se fier.
Je suis sur smartphone là (d'où la réponse partielle précédente) mais je pourrais t'en dire plus plus tard.

 
Malheureusement non, ça m'aurait bien arrangé sinon    
 
Mais je ne sais pas quoi dire de plus pour répondre d'avantage à ta question...   J'ai un lot de factures à envoyer. Mes factures sont représentées sous la forme d'une liste (datagrid). J'aimerai que les lignes soient traitées les unes après les autres, ce qui signifie que côté utilisateur il verra une animation sur la ligne 1 le temps que le nouveau thread lancé soit exécuté, puis une fois le traitement effectué l'animation passera à la ligne 2, puis à la ligne 3, etc.  
 
Ainsi, l'utilisateur verra au fur et à mesure le résultat du traitement (icône succès ou échec).
 
La méthode utilisée (thread ou pas), doit donc lancer un traitement, ne pas bloquer le thread principal (pour permettre les animations et empêcher le freeze de l'écran), puis retourner un résultat avant que le thread principal ne lance le traitement suivant.
 
Mais j'ai pu obtenir une réponse sur un autre forum, dans la boucle qui parcourt la datagrid, il suffit de lancer le traitement comme suit :  
 

 
Cet appel ne bloque pas le thread principal. De plus, le traitement attend la valeur de retour (nResult) pour la traiter (icône succès ou échec dans mon datagrid) et lancer ensuite le traitement suivant.
 
Du coup l'en-tête de ma fonction devient le suivant :
 

 
Ça semble fonctionner comme je l'attend  

C'est pour ça que je te demandais si tu pouvais être bien clair entre asynchrone mais séquentiel, et parallèle. Ton explication texte semblait dire asynchrone, et ton code parallèle.
Comme tu disais ne pas être familier du sujet, je me permets de développer un peu (encore une fois c'est pour aider, ne le prend pas mal comme tu sembles avoir assez mal pris mon premier post) :
Sur une machine moderne, ça serait complètement sensé de vouloir lancer en parallèle autant de traitements que possible, il aurait juste
- fallu limiter la concurrence pour éviter des effets de bord et des ralentissements contre productifs (problème d'IO, problèmes de concurrence, context-switching...)
- Gérer l'ordre d'exécution pour que ça "suive" l'ordre de la grille.

Mais tu as répondu : ce que tu voulais c'est juste de l'asynchrone, non bloquant pour l'UI, pas du parallèle. Donc pas besoin de gérer tout ça (même si encore une fois selon la durée de tes traitements ça pourrait être intéressant pour accélérer l'ensemble, d'où le fait de demander combien de lignes on aura dans la grille et cie).  

Pour ton cas, effectivement la solution est plutôt simple : il suffit (en gros) d'ajouter des await, qui vont permettre que le thread exécutant attende le retour des tâches enfants, afin qu'elles soient jouées une par une.
Alors qu'avec l'exemple de ton premier post, tu lançais toutes les tâches quasiment en même temps, peu importe leur ordre et leur nombre.

Donc là avec simplement await, tu as un truc pas mal. A ta place je serais juste vigilant sur :
- La gestion des erreurs/exceptions dans les tâches enfants (à gérer localement ou à capturer à la fin de la tâche pour ne pas crasher l'ensemble). Parce qu'une exception dans une tâche n'est pas forcément gérée comme dans du code purement synchrone.
- Mettre à jour l'icône au lancement de la tâche, pas juste à la fin (je trouve que c'est plus propre).

Un background worker aurait surement suffit, c'est du windows forms je pari

Oui c'est clair, c'est aussi pour ça que je m'étonnais qu'il parte sur une solution relativement compliquée orientée multi thread alors qu'un BW aurait effectivement suffit.
 
Mais bon, avec les versions récentes de .Net faire du async / await, c'est bien aussi, et ça permet d'avoir un truc utilisable hors UI (alors que le background worker est justement orienté Winform). Donc vu que ça fonctionnera très bien, pas la peine de tout changer .

C'est une bibliothèque de classe mais qui utilise des winform effectivement. Comme l'a bien souligné TotalRecall, si la solution qu'on ma proposé (et que je comprends) fonctionne et qu'elle est propre, je vais rester dessus.
 
Les background worker, je connais pas, mais je vais me documenter car ça m'a l'air intéressant. Merci pour l'info  

Les BW c'est le truc typique en .Net 1 / 2 pour faire des traitements asynchrones non bloquants dans du Winform avec le minimum de code, sachant qu'à l'époque sans ça il aurait fallu faire joujou avec les Threads à la main. C'est facile et pratique, mais old school.

Oui, je suis en train de regarder et c'est exactement ce dont j'aurai eu besoin. Ce que je comprends pas c'est que durant mes multiples recherches je ne suis jamais tombé sur ça    
 
Mais il y a une chose que vous pouviez pas deviner sans plus de code, et que j'aurai du vous préciser, c'est que dans ma fonction matache() j'utilise un objet HttpClient(), c'est pourquoi je m'étais dirigé vers une tâche asynchrone.  
 

Généralement .ConfigureAwait(true) ne sert à rien. Et la version avec false fait des trucs moches.
En gros quand c'est possible il vaut mieux ne pas appeler du tout ConfigureAwait.

ok, j'essaierai de supprimer ce morceau de code, surtout si c'est inutile