¿Las tareas de .Net 4.0 deben ser siempre el método preferido para las aplicaciones de múltiples subprocesos?

Question

que estaba leyendo acerca de la Task Parallel Library y el artículo decía:

En .NET Framework 4, las tareas son la API preferido para la escritura multi-hilo, asíncrona y código paralelo

Pero también dice que usan el ThreadPool detrás de las escenas. Lo que me cuesta entender es si Tasks solo debe usarse cuando uses ThreadPool (y entonces "Thread versus Task" sería equivalente a "Thread versus ThreadPool"), o si Microsoft tiene la intención de que se usen tareas. en cualquier lugar se requieren múltiples hilos, sin las consideraciones inherentes al dilema "Thread versus ThreadPool".

Por lo tanto, si las tareas se utilizan en cualquier lugar, se requieren varios hilos?

Answer 1

La ventaja de diseño del uso de tareas es que entrega los detalles del hilo al tiempo de ejecución, lo que presumiblemente podría llevar a cabo las tareas de subprocesamiento con una solución menos defectuosa y más óptima. Sé que ciertos paradigmas basados ​​en tareas, como PLINQ, le permiten indicar qué estrategia debe adoptar el tiempo de ejecución, de modo que la cuestión de "Threadpool or not to Threadpool" se pueda manejar directamente.

El cambio a este modelo es análogo al cambio a un lenguaje administrado por GC versus un idioma que requiere que limpie su propia memoria. Siempre habrá argumentos a favor de este último, pero Garbage Collection se está optimizando ahora que prácticamente no es un problema. Idealmente, el mecanismo de conmutación en tiempo de ejecución para Tareas evolucionará y mejorará. Así que, en teoría, su aplicación escrita y compilada para .NET 4 podría ser más rápida con mejores implementaciones del tiempo de ejecución, sin más recompilación. Además, el código de enhebrado es notoriamente difícil de corregir, por lo que cualquier mecanismo que oculte esos detalles es bueno para el programador.

Si esos beneficios superan los posibles inconvenientes, como los casos de borde que el tiempo de ejecución no trata bien, es algo que se debe considerar caso por caso. Sin duda, trataría de no optimizar temprano aquí.

Answer 2

Puede usar TaskCreationOptions.LongRunning como una sugerencia para decirle al TPL que su tarea podría estar más involucrada de lo que se ajusta el ThreadPool. Pero, sí, el TPL parece ser el método preferido para la programación multiproceso en el futuro. Microsoft incluso se está construyendo encima para soportar las nuevas palabras clave async y await que se proponen en el Async CTP. No significa que tenga que abandonar las antiguas API de estilo Thread y ThreadPool. Sin embargo, personalmente estoy descubriendo que el TPL hace la mayor parte de lo que quiero en una API más elegante y tiendo a depender de ella casi exclusivamente ahora.

Answer 3

Una tarea es una abstracción de nivel superior a un hilo o un ThreadPool. Esencialmente, usted empaqueta una función en una Tarea y le pide al tiempo de ejecución que la ejecute lo mejor que pueda. Puede tener docenas o cientos de Tareas que se ejecutarán con un número limitado de hilos.

Usando tareas, un desarrollador crea tantas tareas como sea necesario, las encadena para crear flujos (flujos de trabajo en F #) y controla su cancelación sin preocuparse por cómo se asignan o utilizan los hilos. Depende del tiempo de ejecución seleccionar la mejor manera de ejecutar todas las tareas utilizando la cantidad limitada de subprocesos.

Las tareas facilitan la implementación de patrones de programación concurrentes.La biblioteca ParallelExtensionExtras proporciona métodos para convertir pares Begin/EndXXX en tareas que se pueden encadenar y una versión preliminar del modismo de iteración de tareas que utiliza Async CTP para proporcionar la sintaxis async/await. Puede usar una colección concurrente de tareas para crear una cola de trabajos, similar al ejemplo de AsyncCall en ParallelExtensionExtras, o ir más allá y crear agentes similares a Scala, Erlang o F #. El DataFlow en el Async CTP es otro ejemplo de lo que puede crear con las tareas.

Debe tener en cuenta que, si bien una computadora portátil típica tiene 2 núcleos y una computadora de escritorio típica tiene 4, los servidores pequeños ya tienen 8 o más núcleos y pronto tendrán muchos más. Mantener todos esos núcleos ocupados programando manualmente los hilos Y evitar los bloqueos puede convertirse en un gran dolor de cabeza.