Quelle est la différence entre le travail de thread et d'arrière-plan?

Question

C'est en référence à un article « Simplify Asynchronous programming with Tasks » publié dans le magazine MSDN Septembre 2010.

Dans cet article, l'auteur a mis en avant le problème du téléchargement d'un fichier à l'aide WebClient à partir d'une page Web en utilisant HTTP. L'auteur explique qu'une manière de résoudre le problème d'un processus de longue durée qui gèle le thread de l'interface utilisateur est de créer un thread à partir du pool de threads et de le faire exécuter un thread séparé. L'auteur explique que ce n'est pas une bonne solution car plus de processus s'exécutent, le pool de threads finit par créer plus de threads, ce qui affecte les performances. L'auteur poursuit en expliquant qu'une autre stratégie pour résoudre le problème consiste à créer une application basée sur les événements. WebClient met en œuvre des opérations asynchrones via le modèle basé sur les événements. Je suis avec l'auteur jusqu'à présent. Il explique ensuite: «Cette implémentation résout le problème de la solution à base de thread inefficace: le blocage inutile du thread. L'appel à async renvoie immédiatement et ne bloque pas le thread UI ou un thread thread-pool. Le processus s'exécute en arrière-plan '.

Que signifie exactement le mot 'background' ici? En quoi est-ce différent du fil? Merci

Answer 1

"Arrière-plan" dans ce contexte est un thread créé spécifiquement pour gérer la tâche de blocage. Ce n'est pas différent d'un thread ThreadPool sauf pour le fait qu'il ne fait pas partie du pool.

L'utilisation du ThreadPool est évitée car il ne peut allouer qu'un nombre limité de threads (MSDN définit cela comme 250 threads de travail par processeur et 1000 threads d'achèvement d'E/S). Cette limitation est la raison pour laquelle il est acceptable d'effectuer quelques appels bloquants sur les threads ThreadPool, mais si vous effectuez beaucoup d'appels bloquants à partir du pool, il atteindra un point où la file d'attente du ThreadPool commence à être sauvegardée en raison du manque de disponibilité. les travailleurs et la performance se dégrade. Vous pouvez également augmenter le nombre de threads disponibles dans le ThreadPool, mais cela entraîne une pénalité liée aux performances, car chaque Thread dispose de son propre espace de pile alloué depuis la mémoire.

---

Pour ceux lecture, l'article mentionne Nair se trouve ici: http://msdn.microsoft.com/en-us/magazine/ff959203.aspx