En términos de informática, un Task es un futuro o una promesa. (Algunas personas usan esos dos términos sinomímicamente, algunos los usan de manera diferente, nadie puede ponerse de acuerdo en una definición precisa.) Básicamente, un Task<T> "promete" devolverte un T, pero no en este momento cariño, estoy un poco ocupado, ¿por qué no vuelves más tarde?

A Thread es una manera de cumplir esa promesa. Pero no todos Task necesitan un nuevo Thread. (De hecho, crear un hilo es a menudo indeseable, porque hacerlo es mucho más caro que reutilizar un hilo existente de threadpool. Más sobre eso en un momento.) Si el valor que está esperando proviene del sistema de archivos o de una base de datos o de la red, entonces no hay necesidad de que un subproceso se quede sentado y espere los datos cuando pueda atender otras solicitudes. En su lugar, el Task podría registrar una devolución de llamada para recibir los valores cuando estén listos.

En particular, el Task hace no decir por qué es que toma tanto tiempo devolver el valor. podría ser que se tarda mucho tiempo en calcular, o podría ser que se tarda mucho tiempo en obtener. Solo en el primer caso usaría un Thread para ejecutar un Task. (En. NET, los subprocesos son muy caros, por lo que generalmente desea evitarlos tanto como sea posible y realmente solo usarlos si desea ejecutar múltiples cálculos pesados en múltiples CPU. Por ejemplo, en Windows, un hilo pesa 12 KiByte (creo), en Linux, un hilo pesa tan poco como 4 KiByte, en Erlang / BEAM incluso solo 400 Bytes. En. NET, es 1 MiByte!)

Cuando ejecutamos cosas en varios subprocesos, no se garantiza que los subprocesos estén separados entre varios procesadores.

Task es un objeto ligero para gestionar una unidad de trabajo paralelizable. Se puede usar siempre que desee ejecutar algo en paralelo. Paralelo significa que el trabajo se extiende a través de múltiples procesadores para maximizar la velocidad computacional. Las tareas se ajustan para aprovechar los procesadores multicores.

Tarea proporciona siguientes características de gran alcance sobre hilo.

• Si el sistema tiene varias tareas, entonces hace uso del grupo de subprocesos CLR internamente, y por lo tanto no tienen la sobrecarga asociada con la creación un hilo dedicado usando el hilo. También reduce el contexto tiempo de conmutación entre múltiples hilos.
• La tarea puede devolver un resultado.No hay ningún mecanismo directo para devolver el resultado del hilo.

• Espere en un conjunto de tareas, sin una construcción de señalización.

• Podemos encadenar tareas para ejecutar uno tras otro.

• Establecer una relación padre / hijo cuando se inicia una tarea desde otra tarea.

• La excepción de la tarea secundaria se puede propagar a la tarea principal.

• Cancelación de tareas de soporte a través del uso de tokens de cancelación.

• La implementación asincrónica es fácil en la tarea, usando 'async' y palabras clave 'await'.

Hilo

La cosa bare metal, probablemente no necesita usarla, probablemente puede usar una tarea LongRunning y tomar los beneficios de la Biblioteca Paralela TPL - Task, incluida en.NET Framework 4 (febrero, 2002) y superior (también. NET Core).

Tareas

Abstracción sobre los hilos. It utiliza el grupo de subprocesos (a menos que especifique la tarea como una operación LongRunning, si es así, se crea un nuevo subproceso bajo el capó para usted).

Thread Pool

Como el nombre sugiere: un conjunto de hilos. Es el. NET framework manejando un número limitado de subprocesos para usted. ¿Por qué? Porque abrir 100 hilos para ejecutar costosas operaciones de CPU en un Procesador con solo 8 núcleos definitivamente no es una buena idea. El framework mantendrá este pool por ti, reutilizando los subprocesos (no creándolos/matándolos en cada operación), y ejecutando algunos de ellos en paralelo, de manera que tu CPU no se queme.

OK, pero cuando usar cada uno?

En el curriculum vitae: utilice siempre tarea.

La tarea es una abstracción, por lo que es mucho más fácil de usar. Te aconsejo que siempre intentes usar tareas y si te enfrentas a algún problema que te haga necesario manejar un hilo por ti mismo (probablemente el 1% del tiempo), entonces usa hilos.

PERO ten en cuenta que: {[24]]}

• I/O Bound: Para operaciones de E/S bound (llamadas a bases de datos, archivos de lectura/escritura, llamadas a API, etc.) evite usar tareas normales, use LongRunning tareas (o subprocesos si necesita). Porque usar tareas podría te llevará a un grupo de subprocesos con algunos subprocesos ocupados y muchas otras tareas esperando su turno para tomar el grupo.
• CPU Bound: Para las operaciones de CPU bound, simplemente use las tareas normales (que internamente usarán el grupo de subprocesos) y sea feliz.

Puede usar Task para especificar lo que desea hacer y luego adjuntar ese Task con un Thread. de modo que Task se ejecutaría en ese Thread recién creado en lugar de en el subproceso de la interfaz gráfica de usuario.

Use Task con TaskFactory.StartNew(Action action). Aquí se ejecuta un delegado por lo que si no se utiliza ningún subproceso se ejecutará en el mismo subproceso (subproceso GUI). Si mencionas un subproceso puedes ejecutar este Task en un subproceso diferente. Este es un trabajo innecesario porque puede ejecutar directamente el delegado o adjuntar que delega en un subproceso y ejecuta ese delegado en ese subproceso. Así que no lo uses. es innecesario. Si tiene la intención de optimizar su software, este es un buen candidato para ser eliminado.

**Tenga en cuenta que el Action es un delegate.

Además De los puntos anteriores, sería bueno saber que:

1. Una tarea es por defecto una tarea en segundo plano. No puede tener una tarea en primer plano. Por otro lado, un hilo puede ser background o foreground (Use la propiedad IsBackground para cambiar el comportamiento).
2. Las tareas creadas en el grupo de subprocesos reciclan los subprocesos, lo que ayuda a ahorrar recursos. Por lo tanto, en la mayoría de los casos las tareas deben ser su opción predeterminada.
3. Si las operaciones son rápidas, es mucho mejor usar una tarea en lugar de hilo. Para operaciones de larga duración, las tareas no proporcionan muchas ventajas sobre los subprocesos.

La tarea es como una operación que desea realizar , Thread ayuda a administrar esas operaciones a través de múltiples nodos de proceso. la tarea es una opción liviana, ya que el subproceso puede llevar a una administración de código compleja
Sugeriré leer de MSDN (Best in world) siempre

Tarea

Thread

Normalmente uso Task para interactuar con Winforms y simple background worker para que no congele la interfaz de usuario. aquí un ejemplo cuando prefiero usar Task

private async void buttonDownload_Click(object sender, EventArgs e)
{
    buttonDownload.Enabled = false;
    await Task.Run(() => {
        using (var client = new WebClient())
        {
            client.DownloadFile("http://example.com/file.mpeg", "file.mpeg");
        }
    })
    buttonDownload.Enabled = true;
}

VS

private void buttonDownload_Click(object sender, EventArgs e)
{
    buttonDownload.Enabled = false;
    Thread t = new Thread(() =>
    {
        using (var client = new WebClient())
        {
            client.DownloadFile("http://example.com/file.mpeg", "file.mpeg");
        }
        this.Invoke((MethodInvoker)delegate()
        {
            buttonDownload.Enabled = true;
        });
    });
    t.IsBackground = true;
    t.Start();
}

La diferencia es que no necesitas usar MethodInvoker y un código más corto.