Comments 5
Не всё так однозначно.
Result можно использовать после завершения выполнения потока. Например, после WhenAll. Мы создали пару тасок, закинули их внутрь метода, подождали, вытащили результаты.
ConfigureAwait(false) давно можно использовать только там, где это важно. В большинстве случаев, типа API или веб-сервиса, их можно выкинуть из кода без ущерба производительности, при этом улучшив читаемость. Об этом ещё несколько лет назад писали.
Ещё почему-то обошли стороной GetAwaiter().GetResult().
Ещё не всегда обязательно вызывать await, если метод возвращает Task. Иногда не обязательно ждать выполнения, если логика того не требует. Много чего упущено. В т.ч. и то, что в следующей версии async/await будет сильно переработан.
Вообще, если кому-то интересно погрузиться в эту тему глубже, рекомендую статью Стивена Тоуба How async/await really works in C#. Она тянет на книжку по объёму, но даёт хорошее понимание как (и главное почему именно так) устроен async-await в C#.
C# Concurrency NIR DOBOVIZKI
давно есть в переводе даже
На следующей неделе про async/await моя очередь писать
А ещё для продолжения статьи посмотри в сторону async await в .net 11. Они существенно изменили подкапотную логику ))
Асинхронность в c#: как async/await работает внутри и почему не стоит писать .Result