Библиотека шарписта | C#, F#, .NET, ASP.NET

⏳ Урок истории

До .NET 4.5 асинхронный код писали вручную через обратные вызовы и явный маршалинг между потоками. Это было сложно, многословно и доступно только опытным разработчикам. C# 5 и Visual Basic с новым синтаксисом async/await убрали эту сложность.

Что происходит внутри

Компилятор превращает каждый async-метод в конечный автомат. Вот простой пример:

public static async Task SimpleBodyAsync() {
    Console.WriteLine("Hello, Async World!");
}

После компиляции это превращается примерно в:

public static Task SimpleBodyAsync() {
    var d = new <SimpleBodyAsync>d__0();
    d.<>t__builder = AsyncTaskMethodBuilder.Create();
    d.MoveNext();
    return d.<>t__builder.Task;
}

Плюс отдельная struct с методом MoveNext, блоком try/catch и полями для хранения состояния. JIT не сможет встроить такой метод по месту вызова. Появляются издержки на вызов методов инфраструктуры SetResult, SetException и запись в поля конечного автомата.

Когда async лишний

Если метод всегда выполняется синхронно, оборачивать его в async нет смысла. Тауб приводит пример MemoryStream.ReadAsync: чтение из памяти и без того быстрое, и каждый вызов будет создавать новый объект Task<int> просто чтобы вернуть число.

Решение: возвращать кешированный результат вручную.

private Task<int> m_lastTask;

public override Task<int> ReadAsync(
    byte[] buffer, int offset, int count,
    CancellationToken cancellationToken)
{
    int numRead = this.Read(buffer, offset, count);
    return m_lastTask != null && numRead == m_lastTask.Result
        ? m_lastTask
        : (m_lastTask = Task.FromResult(numRead));
}

Это позволяет при повторяющихся вызовах с одним и тем же результатом не создавать новые объекты совсем.

SynchronizationContext и лишние переходы

По умолчанию await захватывает текущий SynchronizationContext и возвращает продолжение в него. Для UI-потока это удобно: не нужно вручную делать маршалинг. Но в библиотечном коде это создаёт лишние переходы между потоками.

Если из UI-потока запустить цикл копирования с await на каждой операции чтения и записи мегабайта данных, получится более 500 переходов из фоновых потоков обратно в UI-поток. Чтобы этого избежать, в библиотеках следует использовать ConfigureAwait(false):

while ((numRead = await source.ReadAsync(buffer, 0, buffer.Length)
    .ConfigureAwait(false)) > 0)
{
    await destination.WriteAsync(buffer, 0, numRead)
        .ConfigureAwait(false);
}

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

Локальные переменные и сбор мусора

Компилятор поднимает все локальные переменные асинхронного метода в поля конечного автомата, который упаковывается в кучу при первом реальном ожидании. На момент выхода статьи компиляторы поднимали иногда больше переменных, чем нужно: даже те, что после await уже не читались.

// Лишнее поле в конечном автомате
public static async Task FooAsync() {
    var dto = DateTimeOffset.Now;
    var dt  = dto.DateTime;
    await Task.Yield();
    Console.WriteLine(dt);
}

// Лучше так:
public static async Task FooAsync() {
    var dt = DateTimeOffset.Now.DateTime;
    await Task.Yield();
    Console.WriteLine(dt);
}

Чем больше объектов создаётся, тем чаще срабатывает сборщик мусора. Это влияет на всю систему, а не только на конкретный метод.

Меньше await — лучше

Каждое await-выражение несёт накладные расходы. Если нужно подождать несколько задач, лучше объединить их через Task.WhenAll, чем ждать по одной:

// Хуже: три отдельных await
int ra = await a;
int rb = await b;
int rc = await c;

// Лучше: одно await на все три
int[] results = await Task.WhenAll(a, b, c);

async/await упростил жизнь разработчикам, но не отменил необходимость понимать, что происходит внутри.

➡️

Блог разработчиков

📍 Навигация: Вакансии • Задачи • Собесы

🐸

Библиотека шарписта

#sharp_view

Please open Telegram to view this post