Tutoriel pour apprendre à programmer avec les pools de threads en C#

Version imprimable

01/09/2016, 13h09
François DORIN

Tutoriel pour apprendre à programmer avec les pools de threads en C#

Bonjour à toutes et à tous,

Je vous propose un tutoriel pour apprendre l'utilisation du pool de threads en programmation C#. Vous pouvez le consulter à l'adresse suivante : http://fdorin.developpez.com/tutorie...eadpool/part1/

Bonne lecture, et n'hésitez pas à apporter vos commentaires ;)

:fleche: Retrouvez les meilleurs et tutoriels pour apprendre la programmation C#
04/09/2016, 20h18
Community Management

Félicitations Dorinf pour cet excellent tutoriel qui peut aider à mieux organiser et optimiser son code pour améliorer les performances des applications programmées en C# :)
05/09/2016, 22h03
François DORIN

Merci !
Le second est dans les tuyaux ;)
07/09/2016, 09h33
lutecefalco

Hello

Je trouve que la 1ère phrase est mal trouvée: "Il existe plusieurs raisons pour vouloir introduire du parallélisme au sein de nos programmes."
Parallélisme et multi thread sont 2 notions différentes
07/09/2016, 10h22
François DORIN

Bonjour lutecefalco,

Tu as raison sur le fait que parallélisme et multi-threading sont deux notions différentes. Le multi-threading est un exemple particulier de parallélisme (tout comme l'utilisation d'instructions vectoriel ou encore l'utilisation d'architectures distribuées).

Maintenant, vue le contexte dans lequel cette phrase se situe, il n'y a aucune ambiguïté. D'autant plus que, d'après mon expérience, la plupart des gens ne sait pas réellement la différence entre ces deux notions et emploi, dans le langage courant, l'un comme l'autre.
07/09/2016, 10h34
lutecefalco

Citation:

Envoyé par dorinf

Maintenant, vue le contexte dans lequel cette phrase se situe, il n'y a aucune ambiguïté.

Je trouve que si justement, ça vient juste après le titre où tu emploies le terme de multi thread

Citation:

Envoyé par dorinf

D'autant plus que, d'après mon expérience, la plupart des gens ne sait pas réellement la différence entre ces deux notions et emploi, dans le langage courant, l'un comme l'autre.

C'est vrai, mais c'est pas une raison.
D'autant plus, que les articles de ce genre sont justement faits pour prêcher la bonne parole ;)
07/09/2016, 10h51
François DORIN

Le "prêchage" de la bonne parole m'a convaincu :-D

Est-ce que "Il existe plusieurs raisons pour vouloir utiliser du multi-tâche au sein de nos programmes" te conviendrais mieux ?
07/09/2016, 10h58
lutecefalco

Citation:

Envoyé par dorinf

Le "prêchage" de la bonne parole m'a convaincu :-D

Est-ce que "Il existe plusieurs raisons pour vouloir utiliser du multi-tâche au sein de nos programmes" te conviendrais mieux ?

Oui :)
07/09/2016, 13h08
François DORIN

Modification faite ;)
13/09/2016, 13h14
Batou_37

Très bonne première partie :)
C'est très clair et précis, merci beaucoup @dorinf.

J'ai eu la chance d’assister à une conf de la part d'Olivier DAHAN sur l'asynchronisme et il est vrai que ce sujet est de plus en plus convoité !

J'attends avec impatience la publication de la deuxième partie ! :)
13/09/2016, 15h03
François DORIN

Merci Batou_37 :)
Je viens de terminer à l'instant la rédaction du second article. Encore quelques jours de patience le temps qu'il soit relu avant publication ;)
13/09/2016, 15h45
Batou_37

Impeccable ! :)

On va attendre ces quelques jours paisiblement :)

Encore merci !
23/09/2016, 13h27
Batou_37

Double Post

Salut dorinf,

Est ce que la publication de la 2ième partie est pour bientôt? :D A moins que je l'ai loupé dans le fil d'actualité de developpez :)
23/09/2016, 14h09
François DORIN

Bonjour,

Bientôt, bientôt ! L'article a passé le cap de la relecture technique et est actuellement en relecture orthographique ;)
13/10/2016, 08h33
François DORIN

Tutoriel pour apprendre à programmer avec les pools de threads en C# : deuxième partie

Bonjour à toutes et à tous,

Je vous propose le second tutoriel de la série pour apprendre l'utilisation du pool de threads en programmation C#. Vous pouvez le consulter à l'adresse suivante : http://fdorin.developpez.com/tutorie...eadpool/part2/

Bonne lecture, et n'hésitez pas à apporter vos commentaires

:fleche: Retrouvez les meilleurs et tutoriels pour apprendre la programmation C#
14/10/2016, 06h36
Community Management

Merci Dorinf et félicitations pour cette deuxième partie ;)
16/10/2016, 18h01
François DORIN

Merci !

Maintenant, il faut que je trouve le temps de finir le 3ème volet ;)
02/11/2016, 14h59
lutecefalco

Merci pour le tuto.
Ptite question: le CancellationToken.Cancel(), il ne faut pas plutôt le faire quand la tâche retourne true?
(Ou alors j'ai lu trop vite :))
02/11/2016, 15h11
François DORIN

Citation:

Envoyé par lutecefalco

Ptite question: le CancellationToken.Cancel(), il ne faut pas plutôt le faire quand la tâche retourne true?

Non, c'est bien quand la tâche retourne false. Si la tâche retourne false, c'est que le nombre n'est pas premier car on a trouvé un diviseur. On peut donc arrêter tous les autres calculs.

Si maintenant la tâche retourne true, c'est qu'il n'y a pas de diviseur dans un intervalle donné. Mais il peut potentiellement y en avoir dans d'autres intervalles. On ne doit donc pas interrompre les autres tâches. Est-ce plus clair ainsi ?
02/11/2016, 15h20
lutecefalco

ok on est d'accord, j'ai lu trop vite ^^
19/01/2017, 17h23
François DORIN

Bonjour à toutes et à tous,

Je vous propose le troisième tutoriel de la série pour apprendre l'utilisation du pool de threads en programmation C#. Vous pouvez le consulter à l'adresse suivante : http://fdorin.developpez.com/tutorie...eadpool/part3/

Au programme, l'utilisation des mots-clés async et await.

Bonne lecture, et n'hésitez pas à apporter vos commentaires

:fleche: Retrouvez les meilleurs et tutoriels pour apprendre la programmation C#
19/01/2017, 17h51
lutecefalco

Hello

Tu peux préciser ce que tu veux dire ici : "Avec la plateforme .Net, la programmation asynchrone est généralement multitâche, et lorsque c'est le cas, utilise des threads… du pool de threads !" ?
Car par défaut, async/await ne crée pas de nouveaux threads
19/01/2017, 19h12
François DORIN

Bonjour,

Ce que je veux dire, c'est qu'hormis dans un contexte particulier (par exemple, thread graphique), c'est la configuration par défaut qui est utilisée. Cette configuration utilise le pool de threads, c'est-à-dire que async/await ne créé par directement de nouveau thread, mais demande un thread au pool de threads. Si le pool de threads ne dispose pas de thread disponible, et si la limite max de threads n'est pas atteinte, alors dans ce cas un thread est créé. Mais uniquement dans ce cas. Dans le cas contraire, la tâche est simplement mise en attente.

Maintenant, tu as raison puisqu'en général, async/await ne créé pas de thread, car réutilise un thread déjà existant.
19/01/2017, 20h39
lutecefalco

Hmmm, je ne suis pas d'accord.
Pour moi, le await/async ne fait que "libérer" le thread courant pour faire autre chose et l'async est géré sur ce même thread lors du "call back"
19/01/2017, 23h30
François DORIN

Citation:

Envoyé par lutecefalco

Pour moi, le await/async ne fait que "libérer" le thread courant pour faire autre chose et l'async est géré sur ce même thread lors du "call back"

C'est exact lorsque l'appel à lieu dans le thread graphique. Mais hors thread graphique, le pool de threads est bel et bien utilisé.

Pour t'en convaincre, voici un petit programme a exécuté en mode console :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace AsyncAwaitTest { class Program { static void Main(string[] args) { Console.WriteLine("Thread ID dans le programme principal : {0}", System.Threading.Thread.CurrentThread.ManagedThreadId); Task task = TestTaskAsync(); task.Wait(); Console.Write("Fin du programme"); Console.ReadLine(); } static async Task TestTaskAsync() { await Task.Run(() => { Console.WriteLine("Thread ID de la tâche : {0}", System.Threading.Thread.CurrentThread.ManagedThreadId); }); } } }
Tu pourras constater que l'ID du thread principal est différent de l'ID du thread exécutant la tâche.

Exécuter cet exemple depuis le thread graphique (en le modifiant légèrement, pour faire en sorte que le code contenu dans le Main soit appelé suite à un clic sur un bouton par exemple) va même provoquer un interblocage (car le task.Wait va mettre en attente le thread graphique, qui de se fait ne pourra pas exécuter la tâche, et donc attendra indéfiniment).

Ouais mais là tu triches en passant par Task.Run
Si tu reprends ton exemple de code:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 static void Main(string[] args) { Console.WriteLine(DateTime.Now.ToString("HH:mm.ss")); var t = Async3Times(); t.Wait(); Console.WriteLine(DateTime.Now.ToString("HH:mm.ss")); Console.ReadLine(); } private async static Task Async3Times() { await HelloWorldAsync(); await HelloWorldAsync(); await HelloWorldAsync(); }
Là on attend 12 secondes.
S'il y avait eu création de threads différents et donc exécution en parallèle, ça aurait pris 4 secondes.
Ou alors j'ai zappé un truc, c'est pas trop mon domaine ça

Citation:

Envoyé par lutecefalco

Ouais mais là tu triches en passant par Task.Run

Aucune tricherie. Où il faut que tu m'expliques pourquoi. await attend une instance de Task. Je lui en fournie une.
Citation:
Envoyé par lutecefalco
Si tu reprends ton exemple de code:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 static void Main(string[] args) { Console.WriteLine(DateTime.Now.ToString("HH:mm.ss")); var t = Async3Times(); t.Wait(); Console.WriteLine(DateTime.Now.ToString("HH:mm.ss")); Console.ReadLine(); } private async static Task Async3Times() { await HelloWorldAsync(); await HelloWorldAsync(); await HelloWorldAsync(); }
Là on attend 12 secondes.
S'il y avait eu création de threads différents et donc exécution en parallèle, ça aurait pris 4 secondes.
Ou alors j'ai zappé un truc, c'est pas trop mon domaine ça
Tu as effectivement zappé un truc. Que ton programme s'exécute parallèlement ou séquentiellement n'a aucune incidence ici. Pourquoi ? Car ta méthode Async3Times n'appelle pas 3 fois HelloWordAsync de manière parallèle mais de manière séquentielle. Il l'appelle une première fois et attend la fin de son exécution. Puis, l'appelle une seconde fois et attend la fin de son exécution, avant de l'appeler une troisième fois et d'attendre la fin de son exécution.

Ce qui s'exécute en parallèle dans ton code, c'est la méthode Async3Times qui s'exécute en parallèle de la méthode Main, et l'exécution des méthodes HelloWorldAsync qui s'exécute également sur un autre thread (qui potentiellement peut être le même que celui exécutant Async3Times car lorsque Async3Times est en attente sur un await, il libère le thread l'exécutant).

Le point important, c'est que lorsqu'une tâche est en attente d'une autre sur un await, elle libère le thread exécutant la tâche, au lieu de le bloquer comme le font les méthodes classiques. Pourquoi est-ce important ? Une des raisons justifiant l'introduction de ce concept async/await est de permettre l'écriture quasiment sans modification (juste le mot clé await à rajouter !), dans le thread graphique, de méthodes longues (attendant une communication réseau par exemple) qui ne bloquent pas l'interface graphique.

20/01/2017, 20h53
lutecefalco

Oui donc on a du multi tâches grâce aux tasks, et non via await / async
20/01/2017, 22h41
François DORIN

J'ai envie de dire oui, mais je ne suis pas sûr que tu aies bien compris pourquoi. async/await ne travaille que sur des instances de Task. Donc, là où tu as async/await, tu as forcément des tâches. Async/await est "juste" un sucre syntaxique pour faciliter la gestion de ces tâches (je mets juste entre guillemets car le code généré est sacrément compliqué).

Citation:

Envoyé par François DORIN

Ce qui s'exécute en parallèle dans ton code, c'est la méthode Async3Times qui s'exécute en parallèle de la méthode Main, et l'exécution des méthodes HelloWorldAsync qui s'exécute également sur un autre thread (qui potentiellement peut être le même que celui exécutant Async3Times car lorsque Async3Times est en attente sur un await, il libère le thread l'exécutant).

Je viens de voir que j'ai fais une erreur en disant cela (qui explique peut-être ton incompréhension).
Lorsque le code que tu as donné en exemple appelle la méthode Async3Times, la méthode s'exécute d'abord, non pas sur un thread différent, mais sur le thread courant. Arrivé au premier await, la fonction retourne une valeur (une instance de Task) et l'exécution du programme principal continue.

Ensuite, une fois que la tâche attendue par le await a terminé son exécution, la méthode Async3Times continue son exécution, mais sur un thread différent du thread principal (et donc l'async n'est pas géré sur le même thread lors du "call back" comme tu pouvais l'écrire plus haut, mais l'est pour la portion de code situé avant le premier await (bon, ici, il n'y en a pas) )
25/01/2017, 12h53
tlt

Bonjour.
Juste une remarque: Il y a un problème avec le lien pdf du tuto.
25/01/2017, 13h40
François DORIN

Merci. C'est corrigé.
09/02/2017, 11h01
stailer

Merci pour cet article,

En faisant des tests sur ma classe qui gère une suite de tâche je me suis aperçu que dans certains contextes mon application (une Winform et une autre Wpf) pouvait bloquer en attendant la fin.
J'ai donc pu modifier et corriger le problème.

Cet article est très concret sans blabla théorique inutile. Beau travail.
09/02/2017, 12h38
François DORIN

Merci pour ce retour. Cela fait toujours plaisir à lire :)
19/04/2017, 13h51
François DORIN

Bonjour à toutes et à tous,

Je vous propose le quatrième et dernier tutoriel de la série pour apprendre l'utilisation du pool de threads en programmation C#. Vous pouvez le consulter à l'adresse suivante : http://fdorin.developpez.com/tutorie...eadpool/part4/

Au programme, la réalisation de tâches périodiques !

Bonne lecture, et n'hésitez pas à apporter vos commentaires

:fleche: Retrouvez les meilleurs et tutoriels pour apprendre la programmation C#
19/04/2017, 15h28
ebastien

Bonjour,

Très bon tutoriel et comme à chaque fois, clair et précis. On sent la maîtrise du sujet...
21/04/2017, 12h36
François DORIN

Merci :)

bonjour

j'avais besoin d'une queue de thread enfin d'exécuter des fonctions en queue (façon thread pour libérer le système)
je me doute qu'on aurait pu faire un thread qui exécute chaque fonctions les unes après les autres
ou utiliser une queue dans un thread, mais au final comme je trouve ce code plutôt simple

j'aimerais donc juste savoir si cette solution pourrait être judicieuse
voila mon code

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 public static class ThreadQueue
    {
        private static object mutex = new object();
 
        public static void QueueUserWorkItem(WaitCallback callBack)
        {
            WaitCallback cw = x =>
            {
                lock (mutex)
                {
                    callBack.Invoke(null);
                }
            };
            ThreadPool.QueueUserWorkItem(cw);
            Thread.Sleep(1);
        }       
    }

avec une utilisation suivante

Code:

1
2
3
4
 
 ThreadQueue.QueueUserWorkItem(ThreadProc);
 ThreadQueue.QueueUserWorkItem(ThreadProc2);
 ThreadQueue.QueueUserWorkItem(ThreadProc3);

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
static void ThreadProc(Object stateInfo)
        {
            Console.WriteLine("START 1");
            Thread.Sleep(3000);
            Console.WriteLine("END 1");
        }
        static void ThreadProc2(Object stateInfo)
        {
            Console.WriteLine("START 2.");
            Thread.Sleep(2000);
            Console.WriteLine("END 2.");
        }
        static void ThreadProc3(Object stateInfo)
        {
            Console.WriteLine("START 3.");
            Console.WriteLine("END 3.");
        }

Oui cela devrait marcher (j'ai juste lu, je n'ai pas testé !).

Le mutex permet de s'assurer que les différentes tâches seront exécutées les unes après les autres, et non en même temps. La simplicité ici vient que la gestion du thread qui exécute les fonctions est totalement laissé au système. Pas besoin de le créer soit même.

S'il n'y a pas beaucoup de tâches en attente, c'est méthode est tout à fait acceptable. S'il y en a beaucoup, je recommande l'utilisation d'un sémaphore binaire (=mutex) avec usage de async/await au lieu de l'instruction lock. En effet, avec l'instruction lock, tu vas réquisitionner un thread du pool de thread. Avec async/await, tu vas dire le libérer le temps de l'attente. Pour 3 tâches en attente max, ce n'est pas un soucis. Pour 200, c'est une autre histoire.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 public static class ThreadQueue { private static SemaphoreSlim mutex = new SemaphoreSlim (1, 1); public static void QueueUserWorkItem(WaitCallback callBack) { WaitCallback cw = x => { await semaphoreSlim.WaitAsync(); // on attend de récupérer le mutex try { callBack.Invoke(null); } finally { semaphoreSlim.Release(); // on libère le mutex. Très important le bloc finally ici, car le mutex doit être libérer dans tous les cas, y compris quand il y a une exception dans le callBack ! } }; ThreadPool.QueueUserWorkItem(cw); } }
Juste une remarque : je ne vois pas l'utilité du Thread.Sleep(1); dans la méthode QueueUserWorkItem.