Discussion :

[gorgonite]

Bonsoir,


Ma question est très simple... quelles sont les contraintes dans la création d'un threadpool afin que les threads soient "automatiquement répartis" sur les différents coeurs ?

j'ai commencé un prototype où j'ai banni toutes écritures concurrentes et toutes sections critiques... mais à part impossible d'avoir une répartition correcte sur les quatre coeurs du serveur (muni d'un Intel Core i7 960 si mes souvenirs sont bons, mais ce n'est pas encore le problème )

le fait de limiter le nombre de threads en fonctionnement grâce à une sémaphore implique de rester dans le même espace mémoire... est-ce le point bloquant ?


sinon, il me reste la possibilité de créer N processus, et d'envoyer explicitement les threads s'exécuter sur un coeur, mais j'aimerais éviter si possible de refaire le boulot de l'OS

[The_badger_man]

Tu as les Parallel Extensions dans le Framework 4.

Un article dessus: http://vincentlaine.developpez.com/t...el-extensions/

Plus d'infos
http://msdn.microsoft.com/fr-be/conc...lt(en-us).aspx
http://code.msdn.microsoft.com/ParExtSamples

[gorgonite]

Tu as les Parallel Extensions dans le Framework 4.

j'avais vu mais je tourne sur du 3.5 (et encore, je compte bien me limiter au 2 sur la plupart du code)




edit : au passage, le lien pour télécharger parallel pour le framework 3.5 ne marche plus, il faudrait mettre à jour

[The_badger_man]

C'est parceque ça n'existe plus

C'est seulement dispo pour le 4.0...

[gorgonite]

C'est parceque ça n'existe plus

C'est seulement dispo pour le 4.0...

j'ai remarqué... mais disons que Parallel a également quelques problèmes pour l'usage que je souhaite en faire (je ne serais sûrement pas le seul à utiliser la machine à un instant donné, et je ne saurais pas forcemment quand j'aurais droit de tout utiliser... un seul serveur de calcul réellement puissant pour un labo constituée de multiples équipes. et la communication n'est pas notre point fort ^^)

[gorgonite]

le problème vient de l'utilisation d'une sémaphore pour limiter le nombre de threads en fonctionnement, et ainsi espérer avoir une consommation mémoire un peu raisonnable... dès qu'on s'affranchit de cela (ie qu'on refait du truc bourrin à la Parallel.For ), on n'a plus le problème

[teddyalbina]

Une bonne solution serait de créer une file de threads globale de taille N (n étant le nombre de cpu), et une file de threads pour chaque cpu.

Puis d'écrire un algo pour s'assurer que les threads soient le plus équitablement dans les piles.

[zoubidaman]

Question con: Le threadpool intégré à .Net ne prend pas déjà ce genre de problématique en charge?

[teddyalbina]

Dans dotnet 3.5 ce sont des threads au sens Win32 du terme, le problème étant que le threadpool en soit ne fournit pas de mécanisme de partitionnement.

Un bout de code la dessus :

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
 
        public static void ParallelForEach<T>(IEnumerable<T> source, Action<T> action)
        {
            // Get the number of processors, initialize the number of remaining
            // threads, and set the starting point for the iteration.
            int numProcs = Environment.ProcessorCount;
            int remainingWorkItems = numProcs;
            int nextIteration = 0;
            int exclusiveUpperBound = source.Count();
            const int batchSize = 3;
            using (ManualResetEvent mre = new ManualResetEvent(false))
            {
                // Create each of the work items.
                for (int p = 0; p < numProcs; p++)
                {
                    ThreadPool.QueueUserWorkItem(delegate
                    {
                        int index;
                        while ((index = Interlocked.Add(ref nextIteration, batchSize) - batchSize) < exclusiveUpperBound)
                        {
                            // In a real implementation, we’d need to handle
                            // overflow on this arithmetic.
                            int end = index + batchSize;
                            if (end > 0)
                            {
                                if (end >= exclusiveUpperBound)
                                {
                                    end = exclusiveUpperBound;
                                }
                                for (int i = index; i < end; i++)
                                {
                                    action(source.ElementAt(i));
                                }
                            }
                        }
                        if (Interlocked.Decrement(ref remainingWorkItems) == 0)
                            mre.Set();
                    });
                }
                // Wait for all threads to complete
                mre.WaitOne();
            }
            // return
        }

[zoubidaman]

Il y a un exemple de partitionnement CPU dans les samples de la TPL:

http://blogs.msdn.com/pfxteam/archiv...9/9934811.aspx

[gorgonite]

Question con: Le threadpool intégré à .Net ne prend pas déjà ce genre de problématique en charge?

ben non... c'était moins bon que ma première version avec semaphore pour limiter le nombre de threads

[gorgonite]

Il y a un exemple de partitionnement CPU dans les samples de la TPL:

http://blogs.msdn.com/pfxteam/archiv...9/9934811.aspx

ça revient à utiliser Parallel... comme dit plus haut