Tüm sunucu tarafı kodu için ConfigureAwait'i çağırmak için en iyi yöntem

Sunucu tarafı kodunuz varsa (yani bazıları ApiController) ve işlevleriniz eşzamansız olduğunda - böylece geri döner Task<SomeObject>- çağırdığınız işlevleri beklediğiniz her zaman en iyi yöntem olarak kabul edilir ConfigureAwait(false)mi?

İplik bağlamlarını orijinal iplik bağlamına geri döndürmek zorunda olmadığından daha performanslı olduğunu okumuştum. Ancak, ASP.NET Web Api ile, isteğiniz bir iş parçacığında geliyorsa ve işlevinizin ConfigureAwait(false)son sonucunu döndürürken sizi farklı bir iş parçacığına sokabilecek bazı işlev ve çağrıları bekliyorsanız ApiController.

Aşağıda bahsettiğim şeyin bir örneğini yazdım:

public class CustomerController : ApiController
{
    public async Task<Customer> Get(int id)
    {
        // you are on a particular thread here
        var customer = await SomeAsyncFunctionThatGetsCustomer(id).ConfigureAwait(false);

        // now you are on a different thread!  will that cause problems?
        return customer;
    }
}

Güncelleştirme: ASP.NET Core'da birSynchronizationContext . ASP.NET Core kullanıyorsanız, kullanıp kullanmamanız önemli ConfigureAwait(false)değildir.

ASP.NET "Tam" veya "Klasik" veya her neyse, bu yanıtın geri kalanı hala geçerlidir.

Orijinal gönderi (Core olmayan ASP.NET için):

ASP.NET ekibinin bu videosu, ASP.NET'te kullanma hakkında en iyi bilgiye sahiptir async.

İplik bağlamlarını orijinal iplik bağlamına geri döndürmek zorunda olmadığından daha performanslı olduğunu okumuştum.

Bu, "senkronize etmeniz" gereken tek bir UI iş parçacığının bulunduğu UI uygulamaları için geçerlidir.

ASP.NET'te durum biraz daha karmaşıktır. Bir asyncyöntem yürütmeyi sürdürdüğünde, ASP.NET iş parçacığı havuzundan bir iş parçacığı alır. Bağlam yakalamayı kullanarak devre dışı bırakırsanız ConfigureAwait(false), iş parçacığı yalnızca yöntemi doğrudan yürütmeye devam eder. Bağlam yakalamayı devre dışı bırakmazsanız, iş parçacığı istek bağlamını yeniden girer ve sonra yöntemi yürütmeye devam eder.

Yani ConfigureAwait(false)size ASP.NET bir iş parçacığı atlama kaydetmez; istek içeriğinin yeniden girilmesini önler, ancak bu normalde çok hızlıdır. ConfigureAwait(false) olabilir Eğer bir istek paralel işlem küçük bir miktar yapmaya çalışıyoruz, ama gerçekten TPL bu senaryoların çoğu için daha uygun olup olmadığını yararlı olabilir.

Ancak, ASP.NET Web Api ile, isteğiniz bir iş parçacığında geliyorsa ve ApiController işlevinizin son sonucunu döndürürken potansiyel olarak farklı bir iş parçacığına neden olabilecek ConfigureAwait (false) işlevini çağırırsanız .

Aslında, sadece bir awaitkutu yapmak bunu yapabilir. Senin kez asyncyöntem vurur await, yöntem ama engellenir parçacığı iplik havuzuna geri döner. Yöntem devam etmeye hazır olduğunda, herhangi bir evre iş parçacığı havuzundan kapar ve yöntemi sürdürmek için kullanılır.

ConfigureAwaitASP.NET'te yapılan tek fark , iş parçacığının yöntemi devam ettirirken istek bağlamına girip girmeyeceğidir.

MSDN makalemdeSynchronizationContext ve asyncgiriş blog yayınımda daha fazla arka plan bilgisi var .

Sorunuza kısa bir cevap: Hayır ConfigureAwait(false). Uygulama düzeyinde bu şekilde arama yapmamalısınız .

TL; Uzun cevabın DR versiyonu: Tüketicinizi tanımadığınız ve senkronizasyon bağlamına (inandığım bir kütüphanede olmamalı) ihtiyaç duymadığınız bir kütüphane yazıyorsanız, daima kullanmalısınız ConfigureAwait(false). Aksi takdirde, kitaplığınızdaki tüketiciler eşzamansız yöntemlerinizi engelleyici bir şekilde tüketerek çıkmaza girebilir. Bu duruma bağlıdır.

İşte ConfigureAwaityöntemin önemi hakkında biraz daha ayrıntılı açıklama (blog yazımdan bir alıntı):

Await anahtar sözcüğünü içeren bir yöntem beklerken, derleyici sizin adınıza bir grup kod oluşturur. Bu eylemin amaçlarından biri, UI (veya ana) iş parçacığı ile eşitlemeyi işlemektir. Bu özelliğin temel bileşeni SynchronizationContext.Current, geçerli iş parçacığı için eşitleme bağlamını alan bileşendir . SynchronizationContext.Currentbulunduğunuz ortama bağlı olarak doldurulur. GetAwaiterGörev yöntemi aranır SynchronizationContext.Current. Geçerli senkronizasyon bağlamı boş değilse, bu bekleyiciye aktarılan devam, bu senkronizasyon bağlamına geri gönderilir.

Yeni eşzamansız dil özelliklerini kullanan bir yöntemi engelleme biçiminde tüketirken, kullanılabilir bir SynchronizationContext'iniz varsa bir kilitlenme ile karşılaşırsınız. Bu yöntemleri engelleme tarzında (Bekleme ile Görev yöntemini beklerken veya sonucu doğrudan Görevin Sonuç özelliğinden alırken) tüketirken, ana iş parçacığını aynı anda engellersiniz. Sonunda, Görev threadpool'daki bu yöntem içinde tamamlandığında SynchronizationContext.Current, kullanılabilir ve yakalandığı için devam etmeyi ana iş parçacığına geri göndermeye çağırır . Ancak burada bir sorun var: UI iş parçacığı engellendi ve bir kilitlenme var!

Ayrıca, tam olarak sorunuz için olan iki harika makale:

• Kendinizi Ayağınızdan Çekmek İçin Mükemmel Tarif - C # 5.0 Eşzamansız Dil Özelliklerini Kullanarak Bir Kilitlenme İle Sona Erme
• HTTP API'niz için Eşzamansız .NET İstemci Kütüphaneleri ve Eşzamansız / await'in Kötü Etkileri Farkındalığı

Son olarak, Lucian Wischik'ten tam olarak bu konuda kısa bir video var : Async kütüphane yöntemleri Task.ConfigureAwait (false) kullanmayı düşünmelidir .

Bu yardımcı olur umarım.

ConfigureAwait (false) kullanarak bulduğum en büyük dezavantaj, iş parçacığı kültürünün sistem varsayılanına döndürülmesidir. Örneğin bir kültür yapılandırdıysanız ...

<system.web>
    <globalization culture="en-AU" uiCulture="en-AU" />    
    ...

ve kültürü en-US olarak ayarlanmış bir sunucuda barındırıyorsanız o zaman ConfigureAwait (false) CultureInfo olarak adlandırılmadan önce bulacaksınız. CurrentCulture en-AU'ya dönecek ve en-US alacaksınız. yani

// CultureInfo.CurrentCulture ~ {en-AU}
await xxxx.ConfigureAwait(false);
// CultureInfo.CurrentCulture ~ {en-US}

Uygulamanız kültüre özgü verilerin biçimlendirilmesini gerektiren herhangi bir şey yapıyorsa, ConfigureAwait (false) kullanırken bunu dikkate almanız gerekir.

Aşağıdakilerin uygulanması hakkında bazı genel düşüncelerim var Task:

1. Görev tek kullanımlıktır ancak kullanmamız gerekmemektedirusing .
2. ConfigureAwait4.5 yılında tanıtıldı. Task4.0 yılında tanıtıldı.
3. .NET Threads her zaman içeriği akıtmak için kullanılır (CLR kitabı üzerinden C # 'a bakın) ancak varsayılan uygulamalarında Task.ContinueWithb / c yapmazlar, bağlam anahtarının pahalı olduğu ve varsayılan olarak kapalı olduğu fark edildi.
4. Sorun, bir kütüphane geliştiricisinin istemcilerinin bağlam akışına ihtiyaç duyup duymadığı umurumda olmamalıdır, dolayısıyla bağlamın akıp akmadığına karar vermemelidir.
5. [Daha sonra eklendi] Yetkili bir cevap ve uygun referans olmaması ve bununla mücadele etmeye devam etmemiz, birisinin işini doğru yapmadığı anlamına gelir.

Birkaç var Mesajları konuda ama benim almak - Tuğberk en güzel cevap ek olarak - yani tüm API'ler asenkron açmak ve ideal bağlamı akmalıdır. Zaman uyumsuzluk yaptığınız için, beklemek yerine süreklilikleri kullanabilirsiniz, böylece kütüphanede hiçbir bekleme yapılmadığından ve bağlam korunacak şekilde (HttpContext gibi) akışı sürdürdüğünüz için kilitlenmenin nedeni olmayacaktır.

Sorun, bir kitaplığın eşzamanlı API'yı göstermesi ancak başka bir eşzamansız API kullanmasıdır; bu nedenle kodunuzda Wait()/ kullanmanız gerekir Result.