Tâches vs ThreadPool

J'ai une application en C# avec une liste de travaux à faire. Je suis à la recherche de faire autant de travail que possible en parallèle. Cependant j'ai besoin d'être en mesure de contrôler le montant maximum de tâches en parallèle.

Ce que je comprends de ce qui est possible avec un pool de threads ou avec des Tâches. Y a t il une différence dans laquelle je utiliser? Ma principale préoccupation est d'être capable de contrôler le nombre de threads actifs à la fois.

Êtes-vous absolument sûr que vous avez besoin de contrôler la quantité de fils en cours d'exécution? Ou simplement besoin de contrôler le nombre de pièces en cours de travail?

OriginalL'auteur prestomanifesto | 2011-11-09

  1. 20

    Veuillez jeter un oeil à ParallelOptions.MaxDegreeOfParallelism pour Tasks.

    Je vous conseille d'utiliser des Tâches, parce qu'ils offrent un plus haut niveau d'abstraction que le pool de threads.

    Une très bonne lecture sur le sujet peuvent être trouvées ici. Vraiment, un livre incontournable et c'est gratuit en plus 🙂

    OriginalL'auteur Vladislav Zorov

  2. 5

    Dans le TPL, vous pouvez utiliser le WithDegreeOfParallelism sur un ParallelEnumerable ou ParallelOptions.MaxDegreeOfParallism

    Il y a aussi le CountdownEvent qui peut être une meilleure option si vous êtes juste en utilisant des threads ou des tâches.

    Dans le ThreadPool, lorsque vous utilisez SetMaxThreads mondial pour la AppDomain vous êtes donc susceptible de limiter, sans rapport avec le code inutilement.

    Vous ne pouvez pas définir le nombre de threads de travail ou le nombre d'I/O threads d'achèvement à un nombre plus petit que le nombre de processeurs de l'ordinateur.

    Si le common language runtime est hébergé, par exemple par Internet Information Services (IIS) ou SQL Server, l'hôte peut limiter ou empêcher la modification de la taille du pool de threads.

    Soyez prudent lorsque vous modifiez le nombre maximal de threads dans le pool de threads. Alors que votre code peut bénéficier, les changements pourraient avoir un effet défavorable sur les bibliothèques de code que vous utilisez.

    Réglage de la taille du pool de threads trop grand peut causer des problèmes de performances. Si un trop grand nombre de threads s'exécutent en même temps, la tâche de commutation surcharge devient un facteur important.

    Je suis d'accord avec la réponse que vous devez utiliser TPL dessus de la ThreadPool comme une meilleure abstraction de multi-threading, mais il est possible d'accomplir ce que vous voulez à la fois.

    OriginalL'auteur Paul Tyng

  3. 3

    Dans ce article sur msdn, ils expliquent pourquoi ils recommandent des Tâches au lieu de pool de threads pour le Parallélisme.

    OriginalL'auteur PierrOz

  4. 3

    Tâche ont un très charmant fonctionnalité pour moi, vous pouvez construire des chaînes de tâches. Qui sont exécutés sur certains résultats de la tâche.
    Une fonctionnalité que j'utilise souvent est la suivante: Une Tâche est en cours d'exécution en arrière-plan pour faire une longue course de travail. J'ai de la chaîne de la Tâche B après cela, seulement lors de l'exécution de la Tâche a fini régulièrement et je le configurer pour exécuter en premier plan, afin que je puisse facilement mettre à jour mes commandes avec le résultat de la longue Tâche en cours d'exécution A.

    OriginalL'auteur Fischermaen

  5. 2

    Vous pouvez également créer un sémaphore pour contrôler le nombre de threads peuvent s'exécuter à un moment unique. Vous pouvez créer un nouveau sémaphore et dans le constructeur de spécifier combien de threads simultanés sont en mesure d'utiliser ce sémaphore à un moment unique. Depuis je ne sais pas comment vous allez utiliser les threads, ce serait un bon point de départ.

    Article MSDN sur le Sémaphore de la classe

    -Wesley

    OriginalL'auteur Wesley