Najlepsza praktyka wywoływania ConfigureAwait dla całego kodu po stronie serwera

Krótka odpowiedź na twoje pytanie: nie. Nie powinieneś tak wywoływać ConfigureAwait(false) na poziomie aplikacji.

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

Tutaj jest nieco bardziej szczegółowe wyjaśnienie znaczenia metody ConfigureAwait (cytat z mojego posta na blogu):

Gdy oczekujesz na metodę ze słowem kluczowym wait, kompilator generuje kod w Twoim imieniu. Jednym z celów tego akcja polega na obsłudze synchronizacji z wątkiem UI (lub głównym). Klucz składową tej funkcji jest SynchronizationContext.Current, która pobiera kontekst synchronizacji dla bieżącego wątku. SynchronizationContext.Current jest wypełniana w zależności od środowisko, w którym się znajdujesz. GetAwaiter metoda zadania wyszukuje dla SynchronizationContext.Current. Jeśli aktualny kontekst synchronizacji jest nie null, kontynuacja, która zostanie przekazana do tego wysłane z powrotem do kontekstu synchronizacji.

Podczas używania metody, która używa nowego języka asynchronicznego funkcje, w sposób blokujący, skończysz z impasem, jeśli masz dostępną Synchronizacjękontekst. Podczas spożywania takie metody w sposób blokujący (czekanie na zadanie z Wait metoda lub pobierając wynik bezpośrednio z właściwości Result Zadanie), zablokujesz główny wątek w tym samym czasie. Kiedy ostatecznie zadanie kończy się wewnątrz tej metody w threadpool, to będzie wywoływać kontynuację, aby dodać powrót do głównego wątku ponieważ SynchronizationContext.Current jest dostępna i przechwycona. Ale jest tu problem: wątek UI jest zablokowany i masz impas!

Również, oto dwa świetne Artykuły dla Ciebie, które są dokładnie dla Twojego pytania:

• W 2008 roku, w ramach projektu "the C# 5.0", w ramach projektu "the C # 5.0", w ramach projektu "the C # 5.0", w ramach projektu "the C # 5.0", w ramach projektu "the C # 5.0", w ramach projektu " the C # 5.0.]}
• asynchroniczne Biblioteki klientów. NET dla Twojego HTTP API i świadomość złych efektów asynchronicznych / oczekujących

Wreszcie, jest świetny Krótki film z Lucian Wischik dokładnie na ten temat: metody biblioteki asynchronicznej powinny rozważyć użycie zadania.ConfigureAwait (false) .

Hope this pomaga.

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

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

I jesteś hosting na serwerze, którego kultura jest ustawiona na en-US, to znajdziesz przed ConfigureAwait (false) nazywa się CultureInfo.CurrentCulture zwróci en-AU, a następnie otrzymasz en-US. tj.

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

Jeśli Twoja aplikacja robi coś, co wymaga specyficznego formatowania danych, wtedy musisz o tym pamiętać podczas używania ConfigureAwait (false).

Mam kilka ogólnych przemyśleń na temat implementacji Task:

1. zadanie jest jednorazowe, a my nie powinniśmy używać using.
2. ConfigureAwait został wprowadzony w 4.5. Task został wprowadzony w 4.0.
3. . Net wątki zawsze używane do przepływu kontekstu (patrz C# poprzez książkę CLR), ale w domyślnej implementacji Task.ContinueWith nie b / c okazało się, że przełącznik kontekstowy jest drogi i jest domyślnie wyłączony.
4. problemem jest biblioteka deweloper nie powinien dbać o to, czy jego klienci potrzebują przepływu kontekstu, czy nie, dlatego nie powinien decydować, czy przepływ kontekstu, czy nie.
5. [Dodano później] fakt, że nie ma autorytatywnej odpowiedzi i właściwego odniesienia, a my walczymy o to oznacza, że ktoś nie wykonał swojej pracy dobrze.

Mam kilka postów na ten temat, ale moim zdaniem - oprócz ładnej odpowiedzi Tugberka - jest to, że powinieneś włączyć wszystkie API asynchroniczne i najlepiej przepłynąć kontekst . ponieważ wykonujesz asynchronizację, możesz po prostu użyć kontynuacji zamiast czekać, aby nie spowodować impasu, ponieważ nie ma czekania w bibliotece i zachowujesz przepływ, aby kontekst był zachowany (np. HttpContext).

Problem polega na tym, że biblioteka wystawia synchroniczne API, ale używa innego asynchronicznego API - dlatego musisz użyć Wait()/Result w Twoim kodzie.