Pytanie ConfigureAwait (false) nie jest potrzebny w aplikacjach usługowych Console / Win, prawda?


Używałem async/await na chwilę, ale zagłębił się jeszcze bardziej i przeczytaj wiele porad dotyczących najlepszych praktyk, z których domyślnie zawsze korzystasz ConfigureAwait(false) aby zapobiec zakleszczeniom i poprawić wydajność.

Po prostu chcę się upewnić, że czegoś mi nie brakuje, gdy przypuszczam, że to ma zastosowanie tylko wtedy, gdy jest to rzeczywisty prąd SynchronizationContext lub TaskScheduler w grze, prawda?

Jeśli mam aplikację usługi Windows, która odpowiada na komunikaty / polecenia / etc. asynchronicznie, zawsze po prostu używa domyślnego harmonogramu = prawdopodobnie tego samego wątku wątku, którego oczekiwane zakończenie będzie wykonywać kontynuację, w związku z czym nie można uzyskać impasu ani różnicy wydajności ConfigureAwait(false), poprawne?

To nie tak, że nie mogę tego tam umieścić, ale tak bardzo nienawidzę hałaśliwego kodu ...


11
2017-09-12 22:20


pochodzenie


Najlepiej powinieneś napisać kod, który jest modułowy i nie obchodzi go, czy działa w konsoli, w usłudze Windows, w witrynie ASP.NET, czy w projekcie okienkowym (więc tak, powinieneś go umieścić, ponieważ twój kod mógłby być uruchamiany sytuacje, w których byłaby ona potrzebna), ale czasami wiesz, że nie będzie ona używana w takich sytuacjach (więc nie, nie powinieneś tego wkładać). To kwestia stylu kodowania. - Scott Chamberlain


Odpowiedzi:


Ogólnie jest to prawdą. Podczas pracy w scenariuszu Konsola lub Usługa nie ma SynchronizationContext zainstalowane (domyślnie), więc continueOnCapturedContext opcja w ConfigureAwait nie spowoduje żadnego efektu, co oznacza, że ​​można go bezpiecznie usunąć bez zmiany zachowania środowiska wykonawczego.

Jednak mogą istnieć wyjątki, więc często sugerowałbym pisanie kodu, w tym ConfigureAwait(false) w razie potrzeby.

Główne zalety włączenia tej funkcji nawet w konsoli lub aplikacji usługowej to:

  1. Kod stanie się później możliwy do ponownego użycia w innych aplikacjach. Jeśli zdecydujesz się na ponowne użycie tego kodu, nie będziesz musiał wyśledzić błędów, które powstają w wyniku nieuwzględnienia tego.
  2. Jeśli zdarzy ci się zainstalować (lub użyć biblioteki, która instaluje) SynchronizationContext podczas działania zachowanie twoich metod się nie zmieni.

9
2017-09-12 22:26