C # - ThreadPool vs tâches
Comme certains l'ont peut-être vu dans .NET 4.0, ils ont ajouté un nouvel espace de noms System.Threading.Tasks qui est essentiellement ce qui est un moyen, une tâche. Je ne l'utilise que depuis quelques jours, depuis l'utilisation de ThreadPool.
Laquelle est la plus efficace et la moins consommatrice de ressources? (Ou tout simplement mieux dans l'ensemble?)
L'objectif de l'espace de noms Tâches est de fournir une architecture enfichable pour rendre les applications multitâches plus faciles à écrire et plus flexibles.
L'implémentation utilise un objet TaskScheduler pour contrôler la gestion des tâches. Cela a des méthodes virtuelles que vous pouvez remplacer pour créer votre propre gestion des tâches. Les méthodes incluent par exemple
protected virtual void QueueTask(Task task)
public virtual int MaximumConcurrencyLevel
L'utilisation de l'implémentation par défaut entraînera une légère surcharge, car il y a un wrapper autour de l'implémentation des threads .NET, mais je ne m'attendrais pas à ce qu'elle soit énorme.
Il existe une (ébauche) d'implémentation d'un TaskScheduler personnalisé qui implémente plusieurs tâches sur un seul thread ici .
lequel est plus efficace et moins consommateur de ressources?
Peu importe, il y aura très peu de différence.
(Ou tout simplement mieux dans l'ensemble)
La classe Task sera la plus facile à utiliser car elle offre une interface très propre pour démarrer et joindre des threads et transfère des exceptions. Il prend également en charge une forme (limitée) d'équilibrage de charge.
"A partir du .NET Framework 4, le TPL est le moyen préféré pour écrire du code multithread et parallèle."
Thread
Le truc du métal nu, vous n'avez probablement pas besoin de l'utiliser, vous pouvez probablement utiliser une tâche LongRunning et bénéficier de ses fonctionnalités.
Les tâches
Abstraction au-dessus des fils. Il tilise le pool de threads (sauf si vous spécifiez la tâche comme une opération LongRunning, si c'est le cas, un nouveau thread est créé sous le capot pour vous).
Pool de threads
Comme son nom l'indique: un pool de threads. Le framework .NET gère-t-il un nombre limité de threads pour vous? Pourquoi? Parce que l'ouverture de 100 threads pour exécuter des opérations coûteuses sur un processeur avec seulement 8 cœurs n'est certainement pas une bonne idée. Le framework conservera ce pool pour vous, réutilisant les threads (ne les créant/tuant pas à chaque opération) et exécutant certains d'entre eux en parallèle de manière à ce que votre CPU ne brûle pas.
OK, mais quand utiliser chacun d'eux?
En résumé: utilisez toujours les tâches.
La tâche est une abstraction, elle est donc beaucoup plus facile à utiliser. Je vous conseille de toujours essayer d'utiliser des tâches et si vous rencontrez un problème qui vous oblige à gérer un thread par vous-même (probablement 1% du temps), utilisez des threads.
MAIS sachez que:
- I/O Bound: pour les opérations liées aux E/S (appels de base de données, fichiers de lecture/écriture, appels d'API, etc.) n'utilisez jamais de tâches normales, utilisez
LongRunningtâches ou threads si nécessaire, mais pas les tâches normales. Parce que cela vous mènerait à un pool de threads avec quelques threads occupés et beaucoup d'autres tâches en attente de son tour pour prendre le pool. - CPU Bound: Pour les opérations liées au CPU, utilisez simplement les tâches normales et soyez heureux.
La planification est un aspect important des tâches parallèles.
Contrairement aux threads, les nouvelles tâches ne commencent pas nécessairement à s'exécuter immédiatement. Au lieu de cela, ils sont placés dans une file d'attente de travail. Les tâches s'exécutent lorsque leur planificateur de tâches associé les supprime de la file d'attente, généralement lorsque les cœurs deviennent disponibles. Le planificateur de tâches tente d'optimiser le débit global en contrôlant le degré de concurrence du système. Tant qu'il y a suffisamment de tâches et que les tâches sont suffisamment exemptes de dépendances de sérialisation, les performances du programme évoluent avec le nombre de cœurs disponibles. De cette façon, les tâches incarnent le concept de parallélisme potentiel
Comme je l'ai vu sur msdn http://msdn.Microsoft.com/en-us/library/ff963549.aspx
ThreadPool et Task la différence est très simple. Pour comprendre la tâche, vous devez connaître le pool de threads.
ThreadPool est essentiellement une aide à la gestion et à la réutilisation des threads libres. En d'autres termes, un pool de threads est la collection de threads d'arrière-plan.
La définition simple d'une tâche peut être:
Tâche work gère de manière asynchrone l'unité de travail. En termes simples, Task ne crée pas de nouveaux threads. Au lieu de cela, il gère efficacement les threads d'un pool de threads. Les tâches sont exécutées par TaskScheduler, qui met les tâches en file d'attente sur les threads.
Un autre bon point à considérer à propos de la tâche est que lorsque vous utilisez ThreadPool, vous n'avez aucun moyen d'annuler ou d'attendre sur les threads en cours d'exécution (sauf si vous le faites manuellement dans la méthode de thread), mais en utilisant la tâche, il est possible. Corrigez-moi si j'ai tort, s'il-vous plait