Рекомендуется вызывать ConfigureAwait для всего кода на стороне сервера

Когда у вас есть серверный код (то есть какой-то ApiController), и ваши функции асинхронны - поэтому они возвращаются Task<SomeObject>- считается ли наилучшей практикой всякий раз, когда вы ожидаете функции, которые вы вызываете ConfigureAwait(false)?

Я читал, что он более производительный, так как он не должен переключать контексты потока обратно в исходный контекст потока. Однако в ASP.NET Web Api, если ваш запрос поступает в один поток, и вы ожидаете какую-то функцию и вызов, ConfigureAwait(false)которые потенциально могут перевести вас в другой поток, когда вы возвращаете окончательный результат своей ApiControllerфункции.

Я напечатал пример того, о чем я говорю ниже:

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

Обновление: ASP.NET Core не имеетSynchronizationContext . Если вы используете ASP.NET Core, не имеет значения, используете вы его ConfigureAwait(false)или нет.

Для ASP.NET "Полный" или "Классический" или что-то еще, остальная часть этого ответа все еще применяется.

Оригинальный пост (для не Core ASP.NET):

Это видео от команды ASP.NET содержит лучшую информацию об использовании asyncв ASP.NET.

Я читал, что он более производительный, так как он не должен переключать контексты потока обратно в исходный контекст потока.

Это верно для приложений пользовательского интерфейса, где есть только один поток пользовательского интерфейса, с которым вы должны «синхронизироваться» обратно.

В ASP.NET ситуация немного сложнее. Когда asyncметод возобновляет выполнение, он получает поток из пула потоков ASP.NET. Если вы отключите захват контекста с помощью ConfigureAwait(false), тогда поток просто продолжит выполнение метода напрямую. Если вы не отключите захват контекста, поток повторно введет контекст запроса и продолжит выполнение метода.

Так ConfigureAwait(false)что не спасает вас от скачка потока в ASP.NET; это спасает вас от повторного ввода контекста запроса, но обычно это происходит очень быстро. ConfigureAwait(false) может быть полезно, если вы пытаетесь выполнить небольшую параллельную обработку запроса, но на самом деле TPL лучше подходит для большинства этих сценариев.

Однако в ASP.NET Web Api, если ваш запрос поступает в один поток, и вы ожидаете какую-то функцию и вызываете ConfigureAwait (false), которая потенциально может перевести вас в другой поток, когда вы возвращаете конечный результат вашей функции ApiController ,

На самом деле, просто сделать это awaitможет сделать это. Как только ваш asyncметод достигает await, метод блокируется, но поток возвращается в пул потоков. Когда метод готов продолжить, любой поток вырывается из пула потоков и используется для возобновления метода.

Единственное отличие ConfigureAwaitв ASP.NET заключается в том, входит ли этот поток в контекст запроса при возобновлении метода.

У меня есть дополнительная справочная информация в моей статье на MSDNSynchronizationContext и в моем asyncвступительном блоге .

Краткий ответ на ваш вопрос: Нет. Вы не должны звонить ConfigureAwait(false)на уровне приложения, как это.

TL; DR-версия длинного ответа: если вы пишете библиотеку, в которой вы не знаете своего потребителя и не нуждаетесь в контексте синхронизации (чего не следует делать в библиотеке, я полагаю), вы должны всегда использовать ConfigureAwait(false). В противном случае потребители вашей библиотеки могут столкнуться с тупиковыми ситуациями при использовании асинхронных методов в режиме блокировки. Это зависит от ситуации.

Вот немного более подробное объяснение важности ConfigureAwaitметода (цитата из моего поста в блоге):

Когда вы ожидаете метода с ключевым словом await, компилятор генерирует кучу кода от вашего имени. Одной из целей этого действия является обработка синхронизации с потоком пользовательского интерфейса (или основного потока). Ключевым компонентом этой функции является тот, SynchronizationContext.Currentкоторый получает контекст синхронизации для текущего потока. SynchronizationContext.Currentзаполняется в зависимости от среды, в которой вы находитесь. GetAwaiterМетод Task ищет SynchronizationContext.Current. Если текущий контекст синхронизации не равен нулю, продолжение, переданное этому ожидающему, будет отправлено обратно в этот контекст синхронизации.

При использовании метода, который использует новые функции асинхронного языка, в режиме блокировки, вы получите тупик, если у вас есть доступный SynchronizationContext. Когда вы используете такие методы в режиме блокировки (ожидание в методе Task с методом Wait или получение результата непосредственно из свойства Result задачи), вы одновременно заблокируете основной поток. Когда в конечном итоге Задача завершается внутри этого метода в пуле потоков, она будет вызывать продолжение для отправки обратно в основной поток, потому что SynchronizationContext.Currentоно доступно и захвачено. Но здесь есть проблема: поток пользовательского интерфейса заблокирован, и у вас тупик!

Кроме того, вот две отличные статьи для вас, которые именно для вашего вопроса:

• Идеальный рецепт, чтобы выстрелить себе в ногу - покончить с тупиком, используя возможности асинхронного языка C # 5.0
• Асинхронные клиентские библиотеки .NET для вашего HTTP API и осведомленность о плохих эффектах async / await

Наконец, есть отличное короткое видео от Lucian Wischik , посвященное именно этой теме: методы асинхронной библиотеки должны учитывать использование Task.ConfigureAwait (false) .

Надеюсь это поможет.

Самый большой недостаток, который я обнаружил при использовании ConfigureAwait (false), заключается в том, что культура потоков возвращается к системному значению по умолчанию. Если вы настроили культуру, например ...

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

и вы размещаете на сервере, для которого установлена ​​культура en-US, тогда вы обнаружите, что ConfigureAwait (false) будет называться CultureInfo.CurrentCulture вернет en-AU и после того, как вы получите en-US. т.е.

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

Если ваше приложение выполняет какие-либо действия, требующие особого форматирования данных, вам следует помнить об этом при использовании ConfigureAwait (false).

У меня есть некоторые общие мысли о реализации Task:

1. Задача одноразовая, но мы не должны ее использовать using.
2. ConfigureAwaitбыл введен в 4.5. Taskбыл введен в 4.0.
3. Потоки .NET всегда использовались для передачи контекста (см. C # через книгу CLR), но в реализации по умолчанию Task.ContinueWithони не выполняются, поскольку выяснилось, что переключение контекста стоит дорого, и по умолчанию оно отключено.
4. Проблема заключается в том, что разработчику библиотеки не нужно заботиться о том, нужен ли ее клиентам поток контекста или нет, следовательно, он не должен решать, следует ли передавать контекст контексту или нет.
5. [Добавлено позже] Тот факт, что нет авторитетного ответа и правильной ссылки, и мы продолжаем бороться с этим, означает, что кто-то не выполнил свою работу правильно.

У меня есть несколько постов на эту тему, но в дополнение к хорошему ответу Тагберка, я предпочитаю, чтобы вы включили все API-интерфейсы асинхронно и в идеале передавали контекст. Поскольку вы выполняете асинхронное выполнение, вы можете просто использовать продолжения вместо ожидания, поэтому не будет возникать тупиковой ситуации, поскольку в библиотеке не выполняется ожидание, и вы продолжаете работу, поэтому контекст сохраняется (например, HttpContext).

Проблема в том, что библиотека предоставляет синхронный API, но использует другой асинхронный API - поэтому вам необходимо использовать Wait()/ Resultв своем коде.