C # 'da "dönüş bekliyor" amacı nedir?

Böyle yazma yönteminin olduğu herhangi bir senaryo var mı :

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

bunun yerine:

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

anlamlı olur mu?

Neden iç çağrışımdan return awaitdoğrudan geri dönebiliyorsanız yapı kullanıyorsunuz ?Task<T>DoAnotherThingAsync()

return awaitBirçok yerde kod görüyorum , sanırım bir şey kaçırmış olabilirim. Ama anladığım kadarıyla, bu durumda async / await anahtar sözcüklerini kullanmamak ve doğrudan Görevi döndürmek işlevsel olarak eşdeğer olacaktır. Neden ek awaitkatman ek yükü eklemelisiniz ?

Sinsi bir durum vardır return, normal yöntem ve return awaitde asyncfarklı yöntem davranır: ile birleştirildiğinde using(ya da daha genel olarak, herhangi bir return awaita tryblok).

Bir yöntemin şu iki sürümünü düşünün:

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

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

İlk yöntem olacak nesne kısa sürede aslında tamamlanmadan önce uzun muhtemeldir metot bize. Bu, ilk sürümün muhtemelen hatalı olduğu (çünkü çok yakında atıldığı) anlamına gelirken, ikinci sürüm iyi çalışır.Dispose()FooDoAnotherThingAsync()Foo

İhtiyacınız yoksa async(yani, Taskdoğrudan iade edebilirsiniz ), kullanmayın async.

return awaitYararlı olan iki durum vardır , örneğin iki eşzamansız işleminiz var:

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

asyncPerformans hakkında daha fazla bilgi için , Stephen Toub'un konu hakkındaki MSDN makalesine ve videosuna bakın .

Güncelleme: Çok daha ayrıntılı bir blog yazısı yazdım .

Bunu yapmak istemenin tek nedeni await, önceki kodda başka bir tane varsa veya sonucu bir şekilde döndürmeden önce manipüle ediyorsanız. Bunun olabileceği başka bir yol, try/catchistisnaların ele alınış biçimini değiştiren bir yöntemdir . Bunlardan herhangi birini yapmıyorsanız, o zaman haklısınız, yöntemi yapma yükünü eklemek için hiçbir neden yoktur async.

Sonucu beklemeniz gerekebilecek başka bir durum şudur:

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

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

Bu durumda, GetIFooAsync()sonucunu beklemek gerekir GetFooAsynctipi nedeniyle Tiki yöntem arasındaki farklı ve Task<Foo>doğrudan atanabilir değil Task<IFoo>. Eğer sonuç bekliyor Ama eğer, sadece olur Foohangi olduğu doğrudan atanabilir IFoo. Daha sonra async yöntemi sadece sonucu içeride Task<IFoo>ve dışarıda yeniden paketler .

Aksi takdirde basit "thunk" yöntemi async yapmak bellekte bir async durum makinesi yaratırken async olmayan bir yöntem oluşturmaz. Bu daha çok (daha doğrudur) daha verimli (bu doğru) çünkü millet async olmayan sürümünü kullanmak için işaret ederken, aynı zamanda asmak durumunda, bu yöntemin "dönüş / devam yığını" dahil olduğunu gösteren hiçbir kanıt var anlamına gelir bu da bazen asmayı anlamayı zorlaştırır.

Yani evet, perf kritik olmadığında (ve genellikle değil) tüm bu thunk yöntemlerine async atacağım, böylece daha sonra asılmamı teşhis etmeme yardımcı olacak async durum makinesine sahibim ve ayrıca thunk yöntemleri zamanla geliştiğinde, atmak yerine hatalı görevleri geri getireceklerinden emin olacaklar.

Geri dönüşü kullanmayacaksanız, hata ayıklama sırasında veya istisnalar dışında günlüklerde yazdırıldığında yığın izinizi bozabilirsiniz.

Görevi döndürdüğünüzde, yöntem amacını yerine getirdi ve çağrı yığınının dışında. Kullandığınızda return await, çağrı yığınında bırakıyorsunuz.

Örneğin:

Beklerken kullanırken çağrı yığını: Görevi B'den beklerken B => B'den görevi C'den beklerken

Beklemede değilken çağrı yığını : Görevin B'den döndüğü C'den bekleyen bir beklemedir.

Bu da beni karıştırıyor ve önceki cevapların asıl sorunuzun göz ardı ettiğini hissediyorum:

Görevi doğrudan iç DoAnotherThingAsync () çağrısından döndürebildiğinizde neden return await yapısını kullanıyorsunuz?

Eh bazen aslında bir istiyorum Task<SomeType>, ancak çoğu zaman aslında bir örneğini istiyoruz SomeType, görevden sonucudur.

Kodunuzdan:

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

Sözdizimine aşina olmayan bir kişi (örneğin, ben) bu yöntemin a döndürmesi gerektiğini düşünebilir Task<SomeResult>, ancak işaretlendiğinden async, gerçek dönüş türünün olduğu anlamına gelir SomeResult. Sadece kullanırsanız return foo.DoAnotherThingAsync(), derlenmeyecek bir Görev iade edersiniz. Doğru yol, görevin sonucunu döndürmektir return await.