Qual è lo scopo del "ritorno in attesa" in C #?

Esiste uno scenario in cui il metodo di scrittura come questo:

public async Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return await DoAnotherThingAsync();
}

Invece di questo:

public Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return DoAnotherThingAsync();
}

avrebbe senso?

Perché usare il return awaitcostrutto quando puoi tornare direttamente Task<T>dall'invocazione interna DoAnotherThingAsync()?

Vedo il codice con return awaitin così tanti posti, penso che potrei essermi perso qualcosa. Ma per quanto ho capito, non usare parole chiave asincrone / wait in questo caso e restituire direttamente l'attività sarebbe funzionalmente equivalente. Perché aggiungere un sovraccarico aggiuntivo di awaitlivello aggiuntivo ?

C'è un caso subdolo quando returnnel metodo normale e return awaitnel asyncmetodo si comportano diversamente: quando combinato con using(o, più in generale, qualsiasi return awaitin un tryblocco).

Considera queste due versioni di un metodo:

Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return foo.DoAnotherThingAsync();
    }
}

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

Il primo metodo farà Dispose()l' Foooggetto non appena il DoAnotherThingAsync()metodo ritorna, il che è probabilmente molto tempo prima che venga effettivamente completato. Ciò significa che la prima versione è probabilmente difettosa (perché Fooè disposta troppo presto), mentre la seconda versione funzionerà bene.

Se non è necessario async(ovvero, è possibile restituire Taskdirettamente), quindi non utilizzare async.

Ci sono alcune situazioni in cui return awaitè utile, come se avessi due operazioni asincrone da fare:

var intermediate = await FirstAsync();
return await SecondAwait(intermediate);

Per ulteriori informazioni sulle asyncprestazioni, consultare l' articolo MSDN di Stephen Toub e il video sull'argomento.

Aggiornamento: ho scritto un post sul blog che approfondisce molti dettagli.

L'unico motivo per cui vorresti farlo è se ce n'è un altro awaitnel codice precedente o se stai in qualche modo manipolando il risultato prima di restituirlo. Un altro modo in cui ciò potrebbe accadere è attraverso un try/catchche cambia il modo in cui vengono gestite le eccezioni. Se non stai facendo nulla di tutto ciò, allora hai ragione, non c'è motivo di aggiungere il sovraccarico di fare il metodo async.

Un altro caso che potrebbe essere necessario attendere il risultato è questo:

async Task<IFoo> GetIFooAsync()
{
    return await GetFooAsync();
}

async Task<Foo> GetFooAsync()
{
    var foo = await CreateFooAsync();
    await foo.InitializeAsync();
    return foo;
}

In questo caso, GetIFooAsync()deve attendere il risultato di GetFooAsyncperché il tipo di Tè diverso tra i due metodi e Task<Foo>non è direttamente assegnabile a Task<IFoo>. Ma se si attendono il risultato, diventa solo Fooche è direttamente assegnabile a IFoo. Quindi il metodo asincrono riconfeziona il risultato dentro Task<IFoo>e via.

Rendere asincrono il metodo "thunk" altrimenti semplice crea una macchina a stati asincroni in memoria, mentre quella non asincrona no. Mentre ciò può spesso indicare alla gente di utilizzare la versione non asincrona perché è più efficiente (il che è vero) significa anche che in caso di blocco, non hai prove che quel metodo sia coinvolto nello "stack di ritorno / continuazione" che a volte rende più difficile capire l'hang.

Quindi sì, quando perf non è critico (e di solito non lo è) lancerò asincrono su tutti questi metodi thunk in modo da avere la macchina a stati asincrona per aiutarmi a diagnosticare blocchi in seguito, e anche per garantire che se quelli i metodi thunk si sono sempre evoluti nel tempo, saranno sicuri di restituire compiti difettosi invece di lanciare.

Se non utilizzerai return wait, potresti rovinare la traccia dello stack durante il debug o quando viene stampata nei log sulle eccezioni.

Quando si restituisce l'attività, il metodo ha raggiunto il suo scopo ed è fuori dallo stack di chiamate. Quando lo usi return awaitlo lasci nello stack di chiamate.

Per esempio:

Stack di chiamata quando si utilizza wait: A in attesa dell'attività da B => B in attesa dell'attività da C

Call stack quando non si utilizza wait: A in attesa dell'attività da C, che B ha restituito.

Anche questo mi confonde e sento che le risposte precedenti hanno trascurato la tua vera domanda:

Perché utilizzare il valore return wait costrutto quando è possibile restituire direttamente Task dall'invocazione DoAnotherThingAsync () interna?

Beh, a volte in realtà vuoi un Task<SomeType>, ma la maggior parte delle volte in realtà vuoi un'istanza di SomeType, cioè, il risultato dell'attività .

Dal tuo codice:

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

Una persona che non ha familiarità con la sintassi (io, ad esempio) potrebbe pensare che questo metodo dovrebbe restituire a Task<SomeResult>, ma poiché è contrassegnato da async, significa che il suo tipo di ritorno effettivo è SomeResult. Se lo usi return foo.DoAnotherThingAsync(), restituiresti un'attività che non verrà compilata. Il modo corretto è di restituire il risultato dell'attività, quindi il return await.