Discussion :

[Hurin]

Ok, merci SirJulio, je ne peux pas dire que cela me paraisse simple,
même si je pense avoir compris ce dont tu parles, au moins dans les grosses lignes.
Mais, je ne comprends pas ce qu'est le thread du pool !
Si j'ai bien compris c'est un thread particulier, qui n'a pas les paramètres requis pour s'occuper de l'affichage et qui est créé par le programme, mais à quel fin, je n'en ai aucune idée !
Je pense que c'est une demande de m'étouffer sous les détails, mais je préfère en connaître trop que pas assez, donc surtout ne te gênes pas,...

Merci pour toutes ces explications, ça m'aide beaucoup !

PS: Ton rappel sur les delegate n'était pas du tout superflu

[SirJulio]

Salut Hurin,

en fait ce que j'appelle un "thread du pool" est un thread tout à fait normal qui est issu du pool de thread, d'ou le nom. =)

Pour revenir sur le pool, en fait, imagine un panier avec des threads preconfigurés qui n'attendent qu'une chose, qu'on leurs poste des taches. En fait l'idée de faire un pool, vient du fait que bien souvent on créé un thread pour faire une tache assynchrone, mais que ce thread se terminera tres rapidement et si la tache est repetitive, on devra recréer un thread à chaque fois, ce qui en plus d'etre lourd, peut nuire aux performances. Un test pour s'en convaincre :

Code :

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

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
    class Program
    {
        static int i = 0;
        static void Main(string[] args)
        {
            Stopwatch sw = new Stopwatch();
 
 
            sw.Start();
            while (i < 100)
            {
                CreateThread();
            }
            sw.Stop();
            Console.WriteLine(string.Format("Creation thread : {0} Ms", sw.ElapsedMilliseconds));
            sw.Reset();
 
            i = 0;
 
            sw.Start();
            while (i < 100)
            {
                UseThreadPool();
            }
            sw.Stop();
 
            Console.WriteLine(string.Format("Utilistation du pool de thread : {0} Ms", sw.ElapsedMilliseconds));
 
            Console.Read();
        }
 
        static void CreateThread()
        {
            Thread t = new Thread(Task);
            t.Start();
        }
 
        static void UseThreadPool()
        {
            ThreadPool.QueueUserWorkItem(Task);
        }
 
 
        static void Task(object state)
        {
            i++;
        }
    }

Dans ce code, j'appelle 100 fois la meme methode sur un thread crée pour l'occasion, et ensuite 100 fois encore sur un pool de thread. La finalité est la meme, j'execute une tache de maniere asynchrone (c'est à dire, en gros, en meme temps, que le thread principal). Les resultats parlent d'eux memes :

Creation thread : 867 Ms
Utilistation du pool de thread : 5 Ms

l'utilisation du pool de thread est quasi 170 fois plus performante que le creation de thread. Maintenant pour savoir ou est la "Magie", en fait un pool de thread, c'est comme je te le disais un panier rempli de thread preconfiguré et pret à l'emploi, et qui attendent des taches, donc plus besoin de créer de thread le systeme s'en occupent pour toi, et reutilisent les threads precedemment crées, ce qui explique les performances, car créer un thread est long.

Pour l'utilité, c'est assez simple, par exemple dans une application Winforms, tu as ton thread qui gere le control (la Form) (qui sera celui qui a demarré le programme par exemple) qui s'occupe de l'affichage et de la presentation (il dessine les controles, fait les mises a jour necessaires etc). Si jamais, tu lance ce thread dans une activité longue (une requete sur une BDD) ou qui peut pontentiellement prendre un temps infini (une requete reseau ou internet par exemple), et bien ton affichage sera gelé le temps que l'operation se termine, car le thread responsable du Control ne peut plus repondre aux evenements de dessin, de redimmensionnement, etc, et comme tu le verras de base, une form ne peut etre redessiné et géré que par le thread qui l'a créer. La finalité est que tu peux avoir une fenetre qui freeze. Bref ceci explique l'interet du multithreading dans une appli. Pour rapprocher ce concept du le ThreadPool, tu as bien compris que les traitements longs devrait etre realisé dans un thread autre que celui du controle (pour garder une UI reactive), et bien ce pool te permet de faire ca simplement, sans avoir à te soucier de la creation du thread, de sa configuration, de sa reutilisation. Un exemple :

Code :

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

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
    //Form avec deux Button (button1 et button2)
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
 
 
        void TraitementLong(object state)
        {
            //Je simule un traitement long de 5 secs
            Thread.Sleep(5000);
        }
 
        private void button1_Click(object sender, EventArgs e)
        {
            //On appelle la methode sur le thread de la Form
            TraitementLong(null);
        }
 
        private void button2_Click(object sender, EventArgs e)
        {
            //On appelle la methode sur un autre thread
            ThreadPool.QueueUserWorkItem(TraitementLong);
        }
    }

Le premier bouton appelle la methode sur le thread du control, la form est gelée pendant 5 secs (tres enervant), le second "delegue" le traitement à un autre thread, on garde notre thread d'UI inoccupé, la form continue à reagir.

Bref, à retenir, le pool de Thread (representé par la classe static ThreadPool) est une classe pleine de Threads (qui ne sont pas different des threads que tu pourrais créer ou du thread que tu utilises quand tu lances un programme) qui sont preconfigurés, gérés de maniere transparente par le systeme, qui fait ce qu'il faut pour avoir une utilisation performante (reutilisation, pre-creation etc). La plupart de temps quand tu voudras créer des operations assynchrone (ce qui sous entends plusieurs threads), tu te serviras de ce pool ou tu y posteras des taches (ou de maniere implicite le systeme le fera lui meme, par exemple le Timer plus haut, ou la fonction appelé quand l'event Elapsed est lancée, est executé par un thread du pool), mais il se peut que dans certains cas, le pool ne soit pas adapté, et ce du à la preconfiguaration de ses threads, par exemple gerer une Form sur un de ces threads peut eventuellement causer des soucis (je te passe les details, que moi meme j'ai du mal à comprendre, mais c'est un probleme d'apartment du thread et du sous-jacent de Winforms cf msdn pour plus d'infos).

En conclusion, je te renvoie vers tout le chapitre de la msdn traitant du threading, du pool, et consorts, c'est une mine de renseignements. Prepare l'aspirine par contre ! =p

Bon courage.

[Hurin]

OK, merci SirJulio pour ta (tes) réponse(s), ça aide !!!
Et j'irais jeter un oeil sur la msdn, même avec de l'aspirine !
(désolé du retard de la réponse)