Использование ConfigureAwait в .NET

Чтобы ответить на ваши вопросы более прямо:

ConfigureAwait (true): выполняет остальную часть кода в том же потоке, что и код до запуска await.

Не обязательно один и тот же поток, но тот же контекст синхронизации. Контекст синхронизации может решить, как запускать код. В приложении UI это будет тот же поток. В ASP.NET это может быть не тот же поток, но у вас будет доступный HttpContext, как и раньше.

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

Это не так. ConfigureAwait(false) сообщает ему, что контекст не нужен, поэтому код можно запускать где угодно. Это может быть любой поток, который его запускает.

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

Неправильно добавлять к нему .ConfigureAwait(true). ConfigureAwait(true) - значение по умолчанию. Так что, если это то, что вы хотите, вам не нужно это указывать.

2. Когда ConfigureAwait (false) улучшает производительность, а когда нет?

Возврат к контексту синхронизации может занять время, потому что ему, возможно, придется дождаться завершения работы чего-то еще. На самом деле такое случается редко, или время ожидания настолько ничтожно, что вы этого даже не заметите.

3. Если вы пишете для приложения с графическим интерфейсом, но следующие строки не имеют доступа к элементам пользовательского интерфейса. Что следует использовать: ConfigureAwait (false) или ConfigureAwait (true)?

Вы можете использовать ConfigureAwait(false), но я предлагаю вам этого не делать по нескольким причинам:

1. Я сомневаюсь, что вы заметите какое-либо улучшение производительности.
2. Это может привести к параллелизму, которого вы не ожидаете. Если вы используете ConfigureAwait(false), продолжение может выполняться в любом потоке, поэтому у вас могут возникнуть проблемы при доступе к небезопасным для потоков объектам. Такие проблемы возникают нечасто, но могут случиться.
3. Вы (или кто-то другой, поддерживающий этот код) можете добавить код, который будет взаимодействовать с пользовательским интерфейсом позже, и возникнут исключения. Надеюсь, ConfigureAwait(false) легко обнаружить (это может быть другой метод, отличный от того, где выбрасывается исключение), и вы / они знаете, что он делает.

Я считаю, что ConfigureAwait(false) проще вообще не использовать (кроме библиотек). По словам Стивена Туба (сотрудника Microsoft) в ConfigureAwait FAQ:

При написании приложений обычно требуется поведение по умолчанию (вот почему это поведение по умолчанию).

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

ConfigureAwait(false) рекомендуется везде, где возврат к тому же контексту синхронизации (который обычно связан с потоком) не требуется, особенно в библиотеках, которые ожидают чего-то внутри: https://medium.com/bynder-tech/c-why-you-should-use-configureawait-false-in-your-library-code-d7837dce3d7f.

ConfigureAwait(true) (по умолчанию) необходим, когда вам нужен тот же контекст, но в определенных ситуациях может также привести к мертвой блокировке.

Рассмотрим этот код:

void Main()
{
    // creating a windows form attaches a synchronization context to the current thread
    new System.Windows.Forms.Form();
    var task = DoSth();
    Console.WriteLine(task.Result);
}

async Task<int> DoSth()
{
    await Task.Delay(1000);
    return 1;
}

в этом примере из-за не ожидаемой задачи DoSth основной поток пользовательского интерфейса заблокирован ожиданием задачи.Результат - в то же время DoSth заблокирован, потому что он хочет вернуться в поток пользовательского интерфейса после задержки. Это приведет к тупиковой ситуации, и этот код никогда не выполнится до конца. Добавление .ConfigureAwait(false) решает проблему в этом случае.

Использование ConfigureAwait(false) в коде приложения обычно не способствует значительному повышению производительности вашего приложения, потому что обычно вы не await внутри циклов в коде приложения. Например, давайте рассмотрим случай, когда ваше приложение имеет кнопку и асинхронная операция запускается каждый раз, когда пользователь нажимает кнопку, а асинхронная операция включает в себя один await. Вводя 22 символа .ConfigureAwait(false) после этого await, вы уже потеряли сопоставимое время своей жизни, причем время, которое вы можете надеяться сэкономить, от 10 пользователей, которые нажимают эту кнопку каждую минуту, 8 часов в день, в течение 20 лет каждый (~ 35000000 переключений контекста всего = несколько секунд процессорного времени).

И это, прежде чем принимать во внимание время, которое вам нужно подумать о том, можете ли вы безопасно включить эту конфигурацию (в зависимости от того, содержит ли продолжение код, связанный с пользовательским интерфейсом), время, которое вам понадобится, чтобы подтверждать предыдущую оценку каждый раз, когда у вас есть для поддержки / изменения кода и времени, которое вы потеряете на отладку, если ваша оценка окажется неверной.

С другой стороны, если ваш Button_Click обработчик содержит такой код:

private async void Button_Click(object sender, EventArgs e)
{
    var client = new WebClient();
    using var stream = await client.OpenReadTaskAsync("someUrl");
    var buffer = new byte[1024];
    while ((await stream.ReadAsync(buffer, 0, buffer.Length)) > 0)
    {
        //...
    }
}

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