Najlepsza praktyka, aby wywołać ConfigureAwait dla całego kodu po stronie serwera

Jeśli masz kod po stronie serwera (np. Niektóre ApiController), a twoje funkcje są asynchroniczne - więc zwracają się Task<SomeObject>- czy jest najlepszą praktyką, że za każdym razem czekasz na funkcje, które wywołujesz ConfigureAwait(false)?

Przeczytałem, że jest bardziej wydajny, ponieważ nie musi przełączać kontekstów wątków z powrotem do oryginalnego kontekstu wątków. Jednak w przypadku interfejsu ASP.NET Web Api, jeśli twoje zapytanie przychodzi do jednego wątku, a ty czekasz na jakąś funkcję i wywołanie, ConfigureAwait(false)które potencjalnie mogą umieścić cię w innym wątku, gdy zwracasz końcowy wynik działania tej ApiControllerfunkcji.

Poniżej podałem przykład tego, o czym mówię:

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;
    }
}

Aktualizacja: ASP.NET Core nie maSynchronizationContext . Jeśli korzystasz z ASP.NET Core, nie ma znaczenia, czy używasz, ConfigureAwait(false)czy nie.

W przypadku ASP.NET „Full”, „Classic” lub cokolwiek, reszta tej odpowiedzi nadal obowiązuje.

Oryginalny post (dla nie-Core ASP.NET):

Ten film wideo zespołu ASP.NET zawiera najlepsze informacje na temat korzystania asyncz ASP.NET.

Przeczytałem, że jest bardziej wydajny, ponieważ nie musi przełączać kontekstów wątków z powrotem do oryginalnego kontekstu wątków.

Dotyczy to aplikacji interfejsu użytkownika, w których istnieje tylko jeden wątek interfejsu użytkownika, do którego należy „zsynchronizować”.

W ASP.NET sytuacja jest nieco bardziej złożona. Gdy asyncmetoda wznawia wykonywanie, pobiera wątek z puli wątków ASP.NET. Jeśli wyłączysz przechwytywanie kontekstu za pomocą ConfigureAwait(false), wątek będzie kontynuował bezpośrednie wykonywanie metody. Jeśli nie wyłączysz przechwytywania kontekstu, wątek ponownie wejdzie w kontekst żądania, a następnie będzie kontynuował wykonywanie metody.

Więc ConfigureAwait(false)nie oszczędza ci skoku wątku w ASP.NET; oszczędza ci to ponownego wprowadzania kontekstu żądania, ale zwykle jest to bardzo szybkie. ConfigureAwait(false) może być przydatne, jeśli próbujesz wykonać niewielką ilość równoległego przetwarzania żądania, ale tak naprawdę TPL lepiej pasuje do większości tych scenariuszy.

Jednak w przypadku interfejsu ASP.NET Web Api, jeśli twoje zapytanie przychodzi do jednego wątku, a ty czekasz na jakąś funkcję i wywołujesz ConfigureAwait (false), który może potencjalnie umieścić cię w innym wątku, gdy zwracasz końcowy wynik funkcji ApiController .

Właściwie po prostu robienie i awaitmoże to zrobić. Gdy twoja asyncmetoda trafi na await, metoda jest blokowana, ale wątek wraca do puli wątków. Gdy metoda jest gotowa do kontynuacji, dowolny wątek jest pobierany z puli wątków i używany do wznowienia metody.

Jedyną różnicą ConfigureAwaitw ASP.NET jest to, czy wątek wchodzi w kontekst żądania podczas wznawiania metody.

Mam więcej podstawowych informacji w moim artykule MSDNSynchronizationContext i moim asyncblogu wprowadzającym .

Krótka odpowiedź na twoje pytanie: Nie. Nie powinieneś dzwonić ConfigureAwait(false)na takim poziomie aplikacji.

Długa wersja TL; DR długiej odpowiedzi: jeśli piszesz bibliotekę, w której nie znasz konsumenta i nie potrzebujesz kontekstu synchronizacji (którego, jak sądzę, nie powinieneś mieć w bibliotece), zawsze powinieneś jej używać ConfigureAwait(false). W przeciwnym razie konsumenci Twojej biblioteki mogą napotkać impas, wykorzystując metody asynchroniczne w sposób blokujący. To zależy od sytuacji.

Oto nieco bardziej szczegółowe wyjaśnienie znaczenia ConfigureAwaitmetody (cytat z mojego posta na blogu):

Gdy czekasz na metodę ze słowem kluczowym Oczekiwanie, kompilator generuje w twoim imieniu sporo kodu. Jednym z celów tej akcji jest obsługa synchronizacji z wątkiem interfejsu użytkownika (lub głównego). Kluczowym elementem tej funkcji jest SynchronizationContext.Currentkontekst synchronizacji dla bieżącego wątku. SynchronizationContext.Currentjest wypełniany w zależności od środowiska, w którym się znajdujesz. GetAwaiterMetoda Zadania wyszukuje SynchronizationContext.Current. Jeśli bieżący kontekst synchronizacji nie ma wartości zerowej, kontynuacja przekazywana do tego oczekującego zostanie wysłana z powrotem do tego kontekstu synchronizacji.

Podczas korzystania z metody, która korzysta z nowych funkcji języka asynchronicznego, w sposób blokujący, zakończy się impasem, jeśli masz dostępny kontekst synchronizacji. Gdy używasz takich metod w sposób blokujący (czekając na metodę Zadanie z Czekaj lub pobierając wynik bezpośrednio z właściwości Wynik zadania), blokujesz jednocześnie główny wątek. Kiedy ostatecznie zadanie zakończy się wewnątrz tej metody w puli wątków, uruchomi kontynuację, aby wysłać wiadomość z powrotem do głównego wątku, ponieważ SynchronizationContext.Currentjest ona dostępna i przechwycona. Ale jest tutaj problem: wątek interfejsu użytkownika jest zablokowany i masz impas!

Oto dwa świetne artykuły, które są dokładnie na twoje pytanie:

• Idealny przepis na zastrzelenie się w stopę - zakleszczenie przy użyciu asynchronicznych funkcji języka C # 5.0
• Asynchroniczne biblioteki klienta .NET dla twojego API HTTP i świadomość złych efektów async / czekają

Na koniec jest świetny krótki film od Luciana Wischika na ten temat: Metody bibliotek asynchronicznych powinny rozważyć użycie Task.ConfigureAwait (false) .

Mam nadzieję że to pomoże.

Największą wadą, jaką znalazłem przy użyciu ConfigureAwait (false) jest to, że kultura wątków jest przywracana do wartości domyślnych systemu. Jeśli skonfigurowałeś kulturę np. ...

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

i hostujesz na serwerze, którego kultura jest ustawiona na en-US, to przekonasz się, że ConfigureAwait (false) nazywa się CultureInfo. CurrentCulture zwróci en-AU i po uzyskaniu en-US. to znaczy

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

Jeśli twoja aplikacja robi coś, co wymaga specyficznego dla kultury formatowania danych, musisz o tym pamiętać podczas korzystania z ConfigureAwait (false).

Mam kilka ogólnych przemyśleń na temat wdrożenia Task:

1. Zadanie jest jednorazowe, ale nie powinniśmy z niego korzystać using.
2. ConfigureAwaitzostał wprowadzony w 4.5. Taskzostał wprowadzony w wersji 4.0.
3. Wątki .NET zawsze używane do przepływu kontekstu (patrz C # poprzez książkę CLR), ale w domyślnej implementacji Task.ContinueWithnie mają b / c okazało się, że zmiana kontekstu jest droga i domyślnie jest wyłączona.
4. Problem polega na tym, że programista biblioteki nie powinien dbać o to, czy jego klienci potrzebują przepływu kontekstu, czy też nie, dlatego nie powinien decydować, czy przepływ kontekstu, czy nie.
5. [Dodano później] Fakt, że nie ma autorytatywnej odpowiedzi i odpowiedniego odniesienia, a my wciąż o to walczymy, oznacza, że ​​ktoś nie wykonał dobrze swojej pracy.

Mam kilka postów na ten temat, ale moje zdanie - oprócz ładnej odpowiedzi Tugberka - polega na tym, że powinieneś włączyć wszystkie interfejsy API asynchronicznie i idealnie przepłynąć kontekst. Ponieważ wykonujesz asynchronię, możesz po prostu użyć kontynuacji zamiast czekać, więc nie nastąpi zakleszczenie, ponieważ w bibliotece nie zostanie wykonane żadne czekanie, a przepływ zostanie zachowany, więc kontekst zostanie zachowany (na przykład HttpContext).

Problem polega na tym, że biblioteka udostępnia synchroniczny interfejs API, ale korzysta z innego asynchronicznego interfejsu API - dlatego należy użyć Wait()/ Resultw kodzie.