Взаимодействие асинхронного и синхронного кода

1. Введение

Асинхронность в C# — мощный инструмент. Но иногда приходится сталкиваться с ситуацией, когда асинхронный код должен вызываться из синхронного (или наоборот). Кажется, что всё должно "магически" работать, но на практике возможны странные зависания (deadlock), потеря производительности и даже неожиданно… разрушенный пользовательский интерфейс. Причем зачастую баг проявляется только на реальных данных: на бою или у пользователя. Причина часто кроется в неправильном взаимодействии синхронного и асинхронного кода и в неочевидных деталях работы планировщика задач .NET.

Также современные библиотеки и фреймворки делают активное использование асинхронных методов, и вам нужно понимать, как грамотно "вклеить" асинхронный код в существующие синхронные цепочки или, наоборот, как правильно вызвать синхронный код из асинхронного метода.

Краткое повторение: что происходит при await

Когда вы пишете:

await SomeAsyncMethod();

Код "разрывается" на две части: до await и после. Первая часть выполняется до первого ожидающего асинхронного действия (например, до запроса в сеть), а продолжение — после его завершения. Вопрос: где будет исполняться "продолжение"? На том же потоке? На другом? А если мы пишем десктопное приложение (например, WPF или WinForms), а если консольное? Ответ — зависит. И здесь вступает в игру, например, ConfigureAwait.

Что такое SynchronizationContext?

SynchronizationContext — специальный механизм .NET, который позволяет коду "запоминать", где и как должно быть вызвано продолжение асинхронной операции.

• В классических WinForms/WPF приложениях SynchronizationContext гарантирует, что после await оставшаяся часть метода продолжит исполняться на том же потоке, что и UI, чтобы не возникало ошибок "обращение к элементу управления не из того потока".
• В ASP.NET (старом, не Core) SynchronizationContext позволяет восстанавливать HttpContext и продолжать работу с HTTP-запросом.
• В консольных и ASP.NET Core приложениях SynchronizationContext, как правило, отсутствует (равен null), и продолжения выполняются на пуле потоков.

Что такое TaskScheduler?

TaskScheduler — более низкоуровневый механизм. В большинстве случаев вы работаете с TaskScheduler.Default, который использует пул потоков .NET. Он отвечает за то, какие задачи когда и где выполняются.

2. Deadlock при смешивании await и Result/Wait()

Одна из самых знаменитых ловушек в C#:

// Где-то в UI-коде
var result = SomeAsyncMethod().Result;

или

SomeAsyncMethod().Wait();

Всё: приложение "зависло". Почему?

Как это происходит?

1. Вы вызываете асинхронный метод и тут же запрашиваете .Result или .Wait() — то есть "блокируете" текущий поток и ждете окончания асинхронной задачи.
2. SomeAsyncMethod внутри себя делает await, и планирует продолжение на тот же поток через SynchronizationContext, но этот поток уже заблокирован ожиданием Result/Wait().
3. Так как поток уже ждет завершения Result/Wait(), он не может выполнить continuation (продолжение).
4. Всё, deadlock: поток ждет сам себя.

Это особенно легко воспроизвести в UI-приложениях, где весь код выполняется на потоке интерфейса, и все продолжения ждут именно этот поток. В консольных приложениях и ASP.NET Core (без синхронизационного контекста) такие deadlock’и встречаются редко.

Шутка из жизни: Если вам удалось получить deadlock с .Result — поздравляем, вы на пару шагов ближе к званию Senior :D

3. Как правильно встраивать асинхронный код в синхронный?

Рекомендация номер один: асинхронность сверху донизу

Если у вас появился асинхронный метод, пропустите async/await наверх по стеку вызова до самого UI или точки входа. Не делайте "удержание асинхронности" на половине пути.

Плохо (блокирует поток):

// Синхронный метод вызывает асинхронный через .Result
public void DoStuff()
{
    var data = GetDataAsync().Result;
    // ...
}

Хорошо (асинхронность сквозная):

public async Task DoStuffAsync()
{
    var data = await GetDataAsync();
    // ...
}

Если можно — используйте всегда await, а не .Result / .Wait().

4. Но бывают ситуации: надо вызвать async из sync

Переписать всё верхнее дерево на async (лучший вариант — если у вас есть выбор).

Использовать специальные паттерны: например, запускать задачу на отдельном потоке через Task.Run, и уже внутри неё вызывать async-метод.

public void DoStuff()
{
    var result = Task.Run(() => SomeAsyncMethod()).Result;
}

Но: и тут есть нюансы с синхронизацией в UI-приложениях, так что лучше так не делать без большой нужды.

5. Что делает ConfigureAwait(false)?

Иногда вам не нужно, чтобы после await код продолжал выполняться на том же потоке (например, в серверных приложениях или в библиотеке, где не принципиален SynchronizationContext). Наоборот, лучше, чтобы .NET не привязывался к одному потоку — это ускоряет работу!

Синтаксис и принцип работы

await SomeAsyncMethod().ConfigureAwait(false);

• ConfigureAwait(false) говорит: "мне не нужен родной SynchronizationContext, продолжай выполнение где угодно, хоть на другом потоке".
• ConfigureAwait(true) (по умолчанию) — "продолжай выполнение там же, где был вызван await, желательно в том же SynchronizationContext".

Визуальная схема

        ┌─────────────────────────────────────────────────────┐
        │                     SynchronizationContext          │
        └─────────────────────────────────────────────────────┘
                      ↑                             ↑
       (UI-поток)   await SomeAsyncMethod()        Continuation (после await)
                  ──────────────────────────────>  (тот же поток — если ConfigureAwait(true))
                      ↓
                    (любой поток — если ConfigureAwait(false))

Пример использования ConfigureAwait(false) — "библиотечный" код

Представьте, что вы пишете библиотеку, которую может использовать кто угодно: WinForms, WPF, ASP.NET, консольные приложения…

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

public async Task<string> LoadDataFromUrlAsync(string url)
{
    using var client = new HttpClient();
    string content = await client.GetStringAsync(url).ConfigureAwait(false);
    return content;
}

Теперь ваш метод не будет "требовать" выполнения на каком-то конкретном SynchronizationContext. Это безопаснее и производительнее (меньше переключений потоков).

Пример: что происходит с await без ConfigureAwait

Рассмотрим WPF-приложение:

private async void Button_Click(object sender, RoutedEventArgs e)
{
    Button1.Content = "Загрузка...";
    await Task.Delay(2000);  // Имитация долгой операции
    Button1.Content = "Готово!";
}

Task.Delay внутри себя делает "await". По умолчанию после await управление возвращается на поток UI, чтобы можно было дальше обновлять элементы управления.

Если внутри вашей долгой операции вы используете ConfigureAwait(false):

await Task.Delay(2000).ConfigureAwait(false);
Button1.Content = "Готово!";  // Ошибка!

Возникнет исключение: InvalidOperationException: "The calling thread cannot access this object because a different thread owns it."
Потому что теперь "продолжение" выполняется на чужом потоке, и нельзя обращаться к UI.

Вывод: используйте ConfigureAwait(false) только там, где не нужен доступ к UI/контексту.

6. Полезные нюансы

Где и когда использовать ConfigureAwait

Как узнать, есть ли SynchronizationContext?

Можно проверить прямо из кода:

Console.WriteLine(SynchronizationContext.Current == null
    ? "Нет контекста"
    : "Контекст существует");

• В консольных и ASP.NET Core приложениях будет "Нет контекста".
• В WinForms/WPF — "Контекст существует".

Визуализация перехода потоков

sequenceDiagram
    participant MainThread as Главный поток (UI/Console)
    participant ThreadPool as Поток из пула

    MainThread->>SomeAsyncMethod: Вызов метода
    SomeAsyncMethod->>MainThread: await без ConfigureAwait
    Note right of MainThread: После await возвращаемся на тот же поток
    SomeAsyncMethod->>ThreadPool: await с ConfigureAwait(false)
    Note right of ThreadPool: После await можно работать на любом потоке

Краткие правила использования

• Не используйте .Result и .Wait() в UI-коде с асинхронными методами.
• В библиотечном коде строго используйте ConfigureAwait(false) для всех await'ов.
• В UI-приложениях используйте ConfigureAwait(false) только внутри методов, не обращающихся к элементам интерфейса.
• Лучше не смешивать синхронный и асинхронный код без крайней необходимости.
• Если нужно вызвать async из sync — подумайте дважды: нельзя ли всю цепочку сделать async?

7. Типичные ошибки новичков при работе с асинхронностью

Ошибка №1: повсеместное использование .Result или .Wait().
Очень часто разработчики, особенно после пары статей про асинхронность, начинают добавлять .Result или .Wait() везде, чтобы "синхронизировать" вызовы асинхронных методов. На первый взгляд кажется удобным, но на практике это гарантированный путь к deadlock в UI-приложениях. Особенно это опасно, если внутри асинхронных методов не используется ConfigureAwait(false) — поток UI блокируется и не может выполнить продолжение задачи.

Ошибка №2: неправильное или чрезмерное использование ConfigureAwait(false).
Некоторые начинающие разработчики применяют ConfigureAwait(false) повсеместно, даже в коде, который работает с элементами интерфейса. В UI-приложениях это приводит к ошибкам доступа к элементам управления (InvalidOperationException), так как продолжение теперь выполняется на потоке, отличном от UI-потока.

Ошибка №3: забывают, что ConfigureAwait работает только с awaitable-объектами.
Многие считают, что можно использовать ConfigureAwait(false) для любых методов, но на самом деле оно работает только с объектами, которые возвращают Task, Task<T>, ValueTask и другие awaitable-типы. Для синхронных методов ConfigureAwait не имеет никакого эффекта, и ожидание выполнения таких методов не становится асинхронным.

Ошибка №4: смешивание синхронного и асинхронного кода без необходимости.
Попытки вызвать асинхронный метод из синхронного кода без продуманной стратегии (например, через .Result, .Wait() или Task.Run) часто приводят к subtle-багам, потере производительности и сложным для диагностики deadlock. Даже если метод кажется коротким и безопасным, подобные вызовы в цепочке могут нарушить работу всего приложения.

Ошибка №5: недооценка влияния SynchronizationContext.
Новички часто забывают, что продолжение после await может выполняться на том же потоке (UI), если не использовать ConfigureAwait(false). Это приводит к непредсказуемому поведению, особенно при комбинировании UI и библиотечного кода, где ожидания и продолжения переплетаются.