Neden hiç bir yöntemi 'beklemiyorsun' ve sonra hemen geri dönüş değerini sorguluyorsun?

Olarak bu MSDN maddesi , aşağıdaki örnek kodu (biraz kısa tutmak için düzenlenmiş) sağlanmıştır:

public async Task<ActionResult> Details(int? id)
{
    if (id == null)
    {
        return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
    }

    Department department = await db.Departments.FindAsync(id);

    if (department == null)
    {
        return HttpNotFound();
    }

    return View(department);
}

FindAsyncYöntem, bir alır Departmentkendi kimliği tarafından nesne ve bir döner Task<Department>. Daha sonra null olup olmadığını görmek için departman hemen kontrol edilir. Anladığım kadarıyla, bu şekilde Görev'in değerini sormak , beklenen yöntemden elde edilen değer geri gelene kadar kod yürütülmesini engeller ve bu da senkronize bir çağrıdır.

Bunu neden yaptın? Find(id)Yine de hemen engelleyecekseniz , senkronize yöntemi çağırmanız daha kolay olmaz mıydı?

Anladığım kadarıyla, bu şekilde Görev'in değerini sormak, beklenen yöntemden elde edilen değer geri gelene kadar kod yürütülmesini engeller ve bu da senkronize bir çağrıdır.

Tam değil.

Aradığınızda await db.Departments.FindAsync(id)görev gönderilir ve geçerli iş parçacığı diğer işlemler tarafından kullanılmak üzere havuza döndürülür. Yürütme akışı engelleniyor (her departmentşeyi doğru anlarsam hemen kullanmamdan bağımsız olarak ), ancak işlemin makinenin bitmesini beklerken diğer işlerde kullanım için serbesttir (ve bir olay veya tamamlama portu ile bildirilir).

Eğer d.Departments.Find(id)çağırdıysanız, iş parçacığı orada oturur ve işlemin çoğu DB üzerinde yapılsa bile yanıtı bekler.

Disk bağlandığında CPU kaynaklarını etkin bir şekilde boşaltırsınız.

Gerçekten hiçbir örnek, görevi beklemeden önce birkaç satır beklemenin mümkün olmadığını göstermemesinden nefret ediyorum. Bunu düşün.

Foo foo = await getFoo();
Bar bar = await getBar();

Console.WriteLine(“Do some other stuff to prepare.”);

doStuff(foo, bar);

Bu, örneklerin teşvik ettiği kod türüdür ve haklısınız. Bunun çok az bir anlamı var. UI girişine cevap verme gibi başka şeyler yapmak için ana iş parçacığını serbest bırakır, ancak asenkron / beklemenin asıl gücü, potansiyel olarak uzun süredir devam eden bir işin tamamlanmasını beklerken kolayca başka şeyler yapmaya devam edebilmemdir. Yukarıdaki kod “bloke edecek” ve Foo & Bar'ı alana kadar baskı satırını yürütmeyi bekleyecektir. Yine de beklemeye gerek yok. Beklerken bunu işleyebiliriz.

Task<Foo> foo = getFoo();
Task<Bar> bar = getBar();

Console.WriteLine(“Do some other stuff to prepare.”);

doStuff(await foo, await bar);

Şimdi, yeniden yazılmış kodla, durmamız gerekmiyor ve değerlerimizi beklememiz gerekmiyor. Her zaman bu tür fırsatları araştırıyorum. Ne zaman beklediğimiz konusunda akıllı olmak önemli performans iyileştirmelerine yol açabilir. Bugünlerde birçok çekirdeğimiz var.

Buradaki sahnelerin arkasında olan daha çok şey var. Async / Await, sözdizimsel şekerdir. İlk önce FindAsync işlevinin imzasına bakın. Bir Görev döndürür. Zaten anahtar kelimenin büyüsünü görüyorsunuz, bu Görevin bir Departman içinde kutusundan çıkar.

Çağıran fonksiyon engellenmez. Olan, departmana ve beklemede olan anahtar kelimeyi izleyen her şeyin bir kapanmaya kapatılması ve tüm amaç ve amaçlar için Task.ContinueWith yöntemine (FindAsync işlevi otomatik olarak farklı bir iş parçacığında yürütülür) iletilmesidir.

Elbette, sahne arkasına geçen daha çok şey var çünkü işlem orijinal iş parçacığına geri döndürülüyor (böylece bir arkaplan işlemi gerçekleştirirken UI ile senkronize etme konusunda endişelenmenize gerek kalmaz) ve çağıran fonksiyonun Async olması durumunda ( ve eşzamansız olarak adlandırılır) aynı şey yığında olur.

Öyleyse, tuzaklar olmadan, Async operasyonlarının sihrini elde edersiniz.

Hayır hemen geri dönmüyor. Bekleyen, yöntem çağrısını asenkronize eder. FindAsync çağrıldığında, Details yöntemi bitmemiş bir görevle döner. FindAsync bittiğinde, sonucunu departman değişkenine döndürecek ve Detaylar yönteminin geri kalanını devam ettirecektir.

Bir sözleşme gibi "eşzamansız" düşünmeyi seviyorum, "İhtiyacınız olduğunda bunu eşzamanlı olarak uygulayabilirim, ama beni diğer eşzamanlı işlevler gibi de çağırabilirsin" diyen bir sözleşme.

Yani, bir geliştirici işlevler yapıyordu ve bazı tasarım kararları onları "async" olarak bir demet işlevi yapmaya / işaretlemeye yöneltti. Fonksiyonların arayan / tüketicisi karar verirken bunları kullanma özgürlüğüne sahiptir. Dediğiniz gibi, işlev çağrısından hemen önce çağrı bekleyebilir ve bekleyebilir, bu şekilde eşzamanlı bir işlev gibi davranabilirsiniz, ancak isterseniz, beklemeden çağrı yapamazsınız.

Task<Department> deptTask = db.Departments.FindAsync(id);

ve sonra, örneğin, aradığınız işleve 10 satır

Department d = await deptTask;

dolayısıyla asenkronize bir fonksiyon olarak ele alıyor.

Sana kalmış.

“eğer yine de hemen engelleyeceksen” cevabınız "Evet". Sadece hızlı bir cevaba ihtiyaç duyduğunuzda, bekleyen / zaman uyumsuz bir anlam ifade eder. Örneğin, UI dizisi gerçekten eşzamansız bir yönteme gelir, UI dizisi geri döner ve düğme tıklatmasını dinlemeye devam ederken, "bekliyor" ifadesinin altındaki kod diğer iş parçacığı tarafından kesilir ve son olarak sonuç alınır.