En espera de múltiples tareas con diferentes resultados

Tengo 3 tareas:

private async Task<Cat> FeedCat() {}
private async Task<House> SellHouse() {}
private async Task<Tesla> BuyCar() {}

Todos deben ejecutarse antes de que mi código pueda continuar y también necesito los resultados de cada uno. Ninguno de los resultados tiene nada en común

¿Cómo llamo y espero a que se completen las 3 tareas y luego obtengo los resultados?

Después de usar WhenAll, puede extraer los resultados individualmente con await:

var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

await Task.WhenAll(catTask, houseTask, carTask);

var cat = await catTask;
var house = await houseTask;
var car = await carTask;

También puede usar Task.Result(ya que sabe en este punto, todos se han completado con éxito). Sin embargo, recomiendo usarlo awaitporque es claramente correcto, aunque Resultpuede causar problemas en otros escenarios.

Solo awaitlas tres tareas por separado, después de iniciarlas todas.

var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

var cat = await catTask;
var house = await houseTask;
var car = await carTask;

Si está usando C # 7, puede usar un práctico método de envoltura como este ...

public static class TaskEx
{
    public static async Task<(T1, T2)> WhenAll<T1, T2>(Task<T1> task1, Task<T2> task2)
    {
        return (await task1, await task2);
    }
}

... para habilitar una sintaxis conveniente como esta cuando desea esperar en múltiples tareas con diferentes tipos de retorno. Tendría que hacer múltiples sobrecargas para diferentes números de tareas a la espera, por supuesto.

var (someInt, someString) = await TaskEx.WhenAll(GetIntAsync(), GetStringAsync());

Sin embargo, vea la respuesta de Marc Gravell para algunas optimizaciones sobre ValueTask y tareas ya completadas si tiene la intención de convertir este ejemplo en algo real.

Dadas tres tareas FeedCat(), SellHouse()y BuyCar()hay dos casos interesantes: o todos se completan sincrónicamente (por alguna razón, tal vez el almacenamiento en caché o un error), o no lo hacen.

Digamos que tenemos, de la pregunta:

Task<string> DoTheThings() {
    Task<Cat> x = FeedCat();
    Task<House> y = SellHouse();
    Task<Tesla> z = BuyCar();
    // what here?
}

Ahora, un enfoque simple sería:

Task.WhenAll(x, y, z);

pero ... eso no es conveniente para procesar los resultados; normalmente nos gustaría awaiteso:

async Task<string> DoTheThings() {
    Task<Cat> x = FeedCat();
    Task<House> y = SellHouse();
    Task<Tesla> z = BuyCar();

    await Task.WhenAll(x, y, z);
    // presumably we want to do something with the results...
    return DoWhatever(x.Result, y.Result, z.Result);
}

pero esto genera muchos gastos generales y asigna varias matrices (incluida la params Task[]matriz) y listas (internamente). Funciona, pero no es una gran OMI. En muchos sentidos, es más simple usar una asyncoperación y solo awaitcada una a la vez:

async Task<string> DoTheThings() {
    Task<Cat> x = FeedCat();
    Task<House> y = SellHouse();
    Task<Tesla> z = BuyCar();

    // do something with the results...
    return DoWhatever(await x, await y, await z);
}

Contrariamente a algunos de los comentarios anteriores, el uso en awaitlugar de noTask.WhenAll hace ninguna diferencia en la forma en que se ejecutan las tareas (simultáneamente, secuencialmente, etc.). En el nivel más alto, Task.WhenAll es anterior al buen soporte del compilador para async/ await, y fue útil cuando esas cosas no existían . También es útil cuando tiene una variedad arbitraria de tareas, en lugar de 3 tareas discretas.

Pero: todavía tenemos el problema de que async/ awaitgenera mucho ruido de compilación para la continuación. Si es probable que las tareas podrían en realidad completar de forma sincrónica, entonces podemos optimizar esto mediante la construcción de una ruta síncrona con un repliegue asíncrona:

Task<string> DoTheThings() {
    Task<Cat> x = FeedCat();
    Task<House> y = SellHouse();
    Task<Tesla> z = BuyCar();

    if(x.Status == TaskStatus.RanToCompletion &&
       y.Status == TaskStatus.RanToCompletion &&
       z.Status == TaskStatus.RanToCompletion)
        return Task.FromResult(
          DoWhatever(a.Result, b.Result, c.Result));
       // we can safely access .Result, as they are known
       // to be ran-to-completion

    return Awaited(x, y, z);
}

async Task Awaited(Task<Cat> a, Task<House> b, Task<Tesla> c) {
    return DoWhatever(await x, await y, await z);
}

Este enfoque de "ruta de sincronización con recuperación asíncrona" es cada vez más común, especialmente en el código de alto rendimiento donde las terminaciones síncronas son relativamente frecuentes. Tenga en cuenta que no ayudará en absoluto si la finalización siempre es genuinamente asíncrona.

Cosas adicionales que se aplican aquí:

1. con C # reciente, un patrón común es que el asyncmétodo alternativo se implementa comúnmente como una función local:

   Task<string> DoTheThings() {
       async Task<string> Awaited(Task<Cat> a, Task<House> b, Task<Tesla> c) {
           return DoWhatever(await a, await b, await c);
       }
       Task<Cat> x = FeedCat();
       Task<House> y = SellHouse();
       Task<Tesla> z = BuyCar();
   
       if(x.Status == TaskStatus.RanToCompletion &&
          y.Status == TaskStatus.RanToCompletion &&
          z.Status == TaskStatus.RanToCompletion)
           return Task.FromResult(
             DoWhatever(a.Result, b.Result, c.Result));
          // we can safely access .Result, as they are known
          // to be ran-to-completion
   
       return Awaited(x, y, z);
   }

2. preferir ValueTask<T>a Task<T>si hay una buena probabilidad de cosas siempre totalmente sincronizada con muchos diferentes valores de retorno:

   ValueTask<string> DoTheThings() {
       async ValueTask<string> Awaited(ValueTask<Cat> a, Task<House> b, Task<Tesla> c) {
           return DoWhatever(await a, await b, await c);
       }
       ValueTask<Cat> x = FeedCat();
       ValueTask<House> y = SellHouse();
       ValueTask<Tesla> z = BuyCar();
   
       if(x.IsCompletedSuccessfully &&
          y.IsCompletedSuccessfully &&
          z.IsCompletedSuccessfully)
           return new ValueTask<string>(
             DoWhatever(a.Result, b.Result, c.Result));
          // we can safely access .Result, as they are known
          // to be ran-to-completion
   
       return Awaited(x, y, z);
   }

3. si es posible, prefieren IsCompletedSuccessfullya Status == TaskStatus.RanToCompletion; esto ahora existe en .NET Core para Task, y en todas partes paraValueTask<T>

Puede almacenarlos en tareas y luego esperarlos a todos:

var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

await Task.WhenAll(catTask, houseTask, carTask);

Cat cat = await catTask;
House house = await houseTask;
Car car = await carTask;

En caso de que esté tratando de registrar todos los errores, asegúrese de mantener Task. Cuando toda la línea en su código, muchos comentarios sugieren que puede eliminarlo y esperar tareas individuales. Task.WhenAll es realmente importante para el manejo de errores. Sin esta línea, posiblemente deje su código abierto para excepciones no observadas.

var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

await Task.WhenAll(catTask, houseTask, carTask);

var cat = await catTask;
var house = await houseTask;
var car = await carTask;

Imagine FeedCat lanza una excepción en el siguiente código:

var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

var cat = await catTask;
var house = await houseTask;
var car = await carTask;

En ese caso, nunca esperará en houseTask ni en carTask. Hay 3 escenarios posibles aquí:

1. SellHouse ya se completó correctamente cuando FeedCat falló. En este caso estás bien.

2. SellHouse no está completo y falla con la excepción en algún momento. La excepción no se observa y se volverá a generar en el subproceso finalizador.

3. SellHouse no está completo y contiene espera dentro de él. En caso de que su código se ejecute en ASP.NET, SellHouse fallará tan pronto como algunas de las esperas se completen dentro de él. Esto sucede porque básicamente hizo que se disparara y olvidara el contexto de llamada y sincronización se perdió tan pronto como FeedCat falló.

Aquí hay un error que obtendrá para el caso (3):

System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at System.Web.ThreadContext.AssociateWithCurrentThread(Boolean setImpersonationContext)
   at System.Web.HttpApplication.OnThreadEnterPrivate(Boolean setImpersonationContext)
   at System.Web.HttpApplication.System.Web.Util.ISyncContext.Enter()
   at System.Web.Util.SynchronizationHelper.SafeWrapCallback(Action action)
   at System.Threading.Tasks.Task.Execute()
   --- End of inner exception stack trace ---
---> (Inner Exception #0) System.NullReferenceException: Object reference not set to an instance of an object.
   at System.Web.ThreadContext.AssociateWithCurrentThread(Boolean setImpersonationContext)
   at System.Web.HttpApplication.OnThreadEnterPrivate(Boolean setImpersonationContext)
   at System.Web.HttpApplication.System.Web.Util.ISyncContext.Enter()
   at System.Web.Util.SynchronizationHelper.SafeWrapCallback(Action action)
   at System.Threading.Tasks.Task.Execute()<---

Para el caso (2) obtendrá un error similar pero con el seguimiento de la pila de excepción original.

Para .NET 4.0 y versiones posteriores, puede detectar excepciones no observadas utilizando TaskScheduler.UnobservedTaskException. Para .NET 4.5 y posteriores, las excepciones no observadas se tragan de manera predeterminada para .NET 4.0 la excepción no observada bloqueará su proceso.

Más detalles aquí: Manejo de excepciones de tareas en .NET 4.5

Puede usar Task.WhenAllcomo se mencionó o Task.WaitAll, dependiendo de si desea que el hilo espere. Eche un vistazo al enlace para obtener una explicación de ambos.

WaitAll vs WhenAll

Use Task.WhenAlly luego espere los resultados:

var tCat = FeedCat();
var tHouse = SellHouse();
var tCar = BuyCar();
await Task.WhenAll(tCat, tHouse, tCar);
Cat cat = await tCat;
House house = await tHouse;
Tesla car = await tCar; 
//as they have all definitely finished, you could also use Task.Value.

Advertencia hacia adelante

Solo un aviso rápido para aquellos que visitan este y otros subprocesos similares que buscan una forma de paralelizar EntityFramework usando el conjunto de herramientas de tarea async + await + : el patrón que se muestra aquí es sólido, sin embargo, cuando se trata del copo de nieve especial de EF, no lo hará lograr la ejecución paralela a menos y hasta que use una instancia de contexto db (nueva) separada dentro de cada una de las llamadas * Async () involucradas.

Este tipo de cosas es necesario debido a las limitaciones de diseño inherentes a los contextos ef-db que prohíben ejecutar múltiples consultas en paralelo en la misma instancia de contexto ef-db.

Aprovechando las respuestas ya dadas, esta es la forma de asegurarse de que recopila todos los valores incluso en el caso de que una o más de las tareas den como resultado una excepción:

  public async Task<string> Foobar() {
    async Task<string> Awaited(Task<Cat> a, Task<House> b, Task<Tesla> c) {
        return DoSomething(await a, await b, await c);
    }

    using (var carTask = BuyCarAsync())
    using (var catTask = FeedCatAsync())
    using (var houseTask = SellHouseAsync())
    {
        if (carTask.Status == TaskStatus.RanToCompletion //triple
            && catTask.Status == TaskStatus.RanToCompletion //cache
            && houseTask.Status == TaskStatus.RanToCompletion) { //hits
            return Task.FromResult(DoSomething(catTask.Result, carTask.Result, houseTask.Result)); //fast-track
        }

        cat = await catTask;
        car = await carTask;
        house = await houseTask;
        //or Task.AwaitAll(carTask, catTask, houseTask);
        //or await Task.WhenAll(carTask, catTask, houseTask);
        //it depends on how you like exception handling better

        return Awaited(catTask, carTask, houseTask);
   }
 }

Una implementación alternativa que tiene más o menos las mismas características de rendimiento podría ser:

 public async Task<string> Foobar() {
    using (var carTask = BuyCarAsync())
    using (var catTask = FeedCatAsync())
    using (var houseTask = SellHouseAsync())
    {
        cat = catTask.Status == TaskStatus.RanToCompletion ? catTask.Result : (await catTask);
        car = carTask.Status == TaskStatus.RanToCompletion ? carTask.Result : (await carTask);
        house = houseTask.Status == TaskStatus.RanToCompletion ? houseTask.Result : (await houseTask);

        return DoSomething(cat, car, house);
     }
 }

var dn = await Task.WhenAll<dynamic>(FeedCat(),SellHouse(),BuyCar());

si desea acceder a Cat, haga esto:

var ct = (Cat)dn[0];

Esto es muy simple de hacer y muy útil de usar, no hay necesidad de buscar una solución compleja.