ThreadPool.QueueUserWorkItem vs Task.Factory.StartNew

Question

lo que es la diferencia entre el siguiente

ThreadPool.QueueUserWorkItem 

vs

Task.Factory.StartNew 

Si el código anterior se llama 500 veces para una tarea larga significa todo los hilos del grupo de subprocesos se tomarán?

¿O será TPL (segunda opción) lo suficientemente inteligente como para tomar hilos menos o igual a la cantidad de procesadores?

Answer 1

Si usted va a iniciar una tarea de larga duración con TPL, debe especificar TaskCreationOptions.LongRunning, lo que significa que no lo hace horario que en el hilo de la piscina. (EDITAR: Como se señala en los comentarios, este es una decisión específica del planificador, y no es una garantía dura y rápida, pero espero que cualquier planificador de producción sensato evite programar tareas de larga ejecución en un grupo de subprocesos.)

Definitivamente no debe programar una gran cantidad de tareas de larga ejecución en el grupo de subprocesos usted mismo. Creo que actualmente el tamaño predeterminado del grupo de subprocesos es bastante grande (porque a menudo se abusa de esta manera), pero fundamentalmente no se debe usar así.

El objetivo del grupo de subprocesos es evitar tareas cortas que reciben un gran impacto de la creación de un nuevo subproceso, en comparación con el tiempo que realmente se están ejecutando. Si la tarea se ejecutará durante un tiempo prolongado, el impacto de crear un nuevo subproceso será relativamente pequeño de todos modos, y no querrá terminar potencialmente sin subprocesos del grupo de subprocesos. (Es menos probable ahora, pero me hizo experiencia que en las versiones anteriores de .NET.)

Personalmente, si tuviera la opción, sin duda uso TPL con el argumento de que la API Task es bastante agradable - pero do recuerde decirle a TPL que espera que la tarea se ejecute durante un tiempo prolongado.

EDIT: Como se señaló en los comentarios, ver también entrada en el blog del equipo de PFX en choosing between the TPL and the thread pool:

En conclusión, voy a reiterar lo ThreadPool desarrollador del equipo de CLR ya ha declarado:

Task is now the preferred way to queue work to the thread pool. 

EDIT: Además de los comentarios, no se olvide que la TPL le permite utilizar custom schedulers, si realmente desea ...