[Перевод] ValueTask<TResult> — почему, зачем и как?28.08.2019 23:32

Предисловие к переводу

В отличие от научных статей, статьи данного типа сложно переводить «близко к тексту», приходится проводить довольно сильную адаптацию. По этой причине приношу свои извинения, за некоторую вольность, с моей стороны, в обращении с текстом исходной статьи. Я руководствуюсь лишь одной целью — сделать перевод понятным, даже если он, местами, сильно отклоняется от исходной статьи. Буду благодарен за конструктивную критику и правки / дополнения к переводу.

Введение

Пространство имен System.Threading.Tasks и класс Task впервые были представлены в .NET Framework 4. С тех пор, этот тип, и его производный класс Task, прочно вошли в практику программирования на .NET, стали ключевыми аспектами асинхронной модели, реализованной в C# 5, с его async/await. В этой статье я расскажу о новых типах ValueTask/ValueTask, которые были введены с целью повышения производительность асинхронного кода, в тех случаях, когда ключевую роль играют накладные расходов при работе с памятью.

Task

Task служит нескольким целям, но основная из них это «promise» — объект, представляющий возможность ожидать завершение какой-либо операции. Вы инициируете операцию и получаете Task. Этот Task будет завершен, когда завершиться сама операция. При этом, есть три варианта:

1. Операция завершается синхронно, в потоке инициатора. Например, при выполнении доступа к некоторым данным, которые уже находятся в буфере.
2. Операция выполняется асинхронно, но успевает завершиться к тому моменту, когда инициатор получит Task. К примеру, когда выполняется быстрый доступ к данным, которые еще не были буферизированы
3. Операция выполняется асинхронно, и завершается после того как инициатор получил Task Примером может быть получение данных по сети.

Чтобы получить результат асинхронного вызова, клиент может, либо блокировать вызывающий поток в ожидании завершения, что, часто, противоречить идеи асинхронности, либо же предоставить метод обратного вызова, который будет выполнен по завершению асинхронной операции. Модель обратного вызова в .NET 4 была представлена явным образом, посредством метода ContinueWith объекта класса Task, принимавшего на вход делегат, вызываемый по завершению асинхронной операции.

SomeOperationAsync().ContinueWith(task =>
{
    try
    {
        TResult result = task.Result;
        UseResult(result);
    }
    catch (Exception e)
    {
        HandleException(e);
    }
});

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

TResult result = await SomeOperationAsync();
UseResult(result);

Класс Task довольно гибок и имеет ряд преимуществ. Например, вы можете «ожидать» объект этого класса несколько раз, ожидать результата можно конкурентно, любым количеством потребителей. Экземпляры класса можно сохранить в словарь для любого числа последующих вызовов, с целью «ожидания» в будущем. Описанные сценарии, позволяют рассматривать объекты Task в качестве своеобразного кэша результатов, получаемых асинхронно. Кроме того, Task предоставляет возможность блокировать ожидающий поток, до завершения операции, если того требует сценарий. Так же есть т. н. комбинаторы для различных стратегий ожидания завершения наборов задач, например, «Task.WhenAny» — асинхронное ожидание завершения первой, из множества, задач.

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

TResult result = await SomeOperationAsync();
UseResult(result);

Это очень похоже на то, как мы пишем синхронный код (например TResult result = SomeOperation();). Такой вариант естественным образом транслируется в async/await.

Кроме того, при всех достоинствах, тип Task имеет потенциальный недостаток. Task — это класс, а значит, каждая операция, которая создает экземпляр задачи, аллоцирует объект в куче. Чем больше объектов мы создаем, тем больше требуется работы со стороны GC, и тем больше тратиться ресурсов на работу сборщика мусора, ресурсов, которые могли бы быть использованы на другие цели. Это становится явной проблемой для кода, в котором, с одной стороны, экземпляры Task создаются часто, а с другой, к которому предъявляются повышенные требования по пропускной способности и производительности.

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

public async Task WriteAsync(byte value)
{
    if (_bufferedCount == _buffer.Length)
    {
        await FlushAsync();
    }
    _buffer[_bufferedCount++] = value;
}

и, чаще всего, в буфере будет достаточно места, то операция будет завершиться синхронно. Если это так, то нет ничего особенного в возвращаемой задаче, нет возвращаемого значения, а операция уже завершена. Другими словами, мы имеем дело с Task — эквивалентом синхронной void-операции. В таких ситуациях среда выполнения просто кэширует объект Task, и использует его каждый раз как результат для любого async Task — метода, завершающегося синхронно (Task.ComletedTask). Другой пример, допустим вы пишете:

public async Task MoveNextAsync()
{
    if (_bufferedCount == 0)
    {
        await FillBuffer();
    }
    return _bufferedCount > 0;
}

Допустим, так же, что в большинстве случаев, в буфере есть некоторые данные. Метод проверяет _bufferedCount, видит, что переменная больше нуля, и возвращает true. Только если на момент проверки данные не были буферизированы, требуется выполнить асинхронную операцию. Как бы там ни было, есть только два возможных логических результата (true и false), и только два возможных состояния возврата через Task. В расчете на синхронное завершение, или асинхронное, но до выхода из метода, среда выполнения кэширует два экземпляра Task (одно для значения true, второе для false), и возвращает нужный из них, избегая дополнительных аллокаций. Единственный вариант, когда приходится создавать новый объект Task, это случай асинхронного выполнения, которое завершается уже после «возврата». В этом случае, методу приходится создавать новый объект Task, т.к. на момент выхода из метода, результат завершения операции еще не известен. Возвращаемый объект должен быть уникальным, т.к. в него будет, в конечном итоге, сохранен результат асинхронной операции.

Есть и другие примеры подобного кэширования со стороны среды выполнения. Но такая стратегия применима не везде. Например, метод:

public async Task ReadNextByteAsync()
{
    if (_bufferedCount == 0)
    {
        await FillBuffer();
    }

    if (_bufferedCount == 0)
    {
        return -1;
    }

    _bufferedCount--;
    return _buffer[_position++];
}

так же, часто завершается синхронно. Но, в отличие от предыдущего примера, этот метод возвращает целочисленный результат, который имеет примерно четыре миллиарда возможных значений. Для кэширования Task, в этой ситуации, потребовалось бы сотни гигабайт памяти. Среда и здесь поддерживает небольшой кэш для Task, для нескольких небольших значений. Так, например, если операция завершится синхронно (данные присутствуют в буфере), с результатом 4, будет использован кэш. Но если результатом, пусть и синхронного, завершение будет значение 42, будет создан новый объект Task, аналогично вызову Task.FromResult(42).

Многие реализации библиотеки пытаются смягчить подобные ситуации посредством поддержки своих собственных кэшей. Одним из примеров является, перегрузка MemoryStream.ReadAsync. Эта операция, введенная в .NET Framework 4.5, всегда завершается синхронно, т.к. это всего лишь чтение из памяти. ReadAsync возвращает Task, где целочисленный результат представляет число прочитанных байтов. Довольно часто, в коде, встречается ситуация, когда ReadAsync используется в цикле. При этом, если имеются следующие признаки:

• Количество запрашиваемых байтов, не меняется для большинства итераций цикла;
• В большинстве итераций ReadAsync может прочитать запрошенное количество байт.

То, для повторяющихся вызовов ReadAsync выполняется синхронно и возвращает объект Task, с одинаковым результатом от итерации к итерации. Логично, что MemoryStream кэширует крайнюю успешно выполненную задачу, и для всех последующих вызовов, если новый результат совпадает с предыдущим, возвращает экземпляр из кэша. Если же результат не совпадает, то используется Task.FromResult для создания нового экземпляра, который, в свою очередь, так же, кэшируется перед возвратом.

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

ValueTask и синхронное завершение

Все это, в конечном итоге, послужило мотивацией для введения в .NET Core 2.0 нового типа ValueTask. Так же, через nuget-пакет System.Threading.Tasks.Extensions, этот тип сделали доступным и в других релизах .NET.

ValueTask был введен в .NET Core 2.0 как структура, способная оборачивать TResult или Task. Это означает, что объекты этого типа могут быть возвращены из async-метода. Первый плюс от введение этого типа виден сразу: если метод завершился успешно и синхронно, нет необходимости создавать что-либо в куче, достаточно просто для возврата создать экземпляр ValueTask со значением результата. Только если метод завершается асинхронно, нам необходимо создать Task. В таком случае ValueTask используется как обертка над Task. Решение сделать ValueTask способным агрегировать Task было принято с целью оптимизации: и в случае успеха, и в случае неудачи, асинхронный метод создает Task, с точки зрения оптимизации по памяти, лучше агрегировать сам объект Task, чем держать дополнительные поля в ValueTask на разные случаи завершения (например для хранения исключения).

Учитывая вышеизложенное, больше нет необходимости в кэшировании в таких методах как приведенный выше MemoryStream.ReadAsync, вместо этого его можно реализовывать следующим образом:

public override ValueTask ReadAsync(byte[] buffer, int offset, int count)
{
    try
    {
        int bytesRead = Read(buffer, offset, count);
        return new ValueTask(bytesRead);
    }
    catch (Exception e)
    {
        return new ValueTask(Task.FromException(e));
    }
}

ValueTask и асинхронное завершение

Иметь возможность писать асинхронные методы, которые не требуют дополнительных аллокаций памяти для результата, при синхронном завершении, это действительно большой плюс. Как говорилось выше, это было основной целью для введения нового типа ValueTask в .NET Core 2.0. Все новые методы, которые, как ожидается, будут использоваться на «горячих путях», теперь в качестве типа возвращаемого значения вместо Task используют ValueTask. К примеру, новая перегрузка метода ReadAsync для Stream, в .NET Core 2.1 (принимающая в качестве параметра Memory вместо byte[]), возвращает экземпляр ValueTask. Это позволило значительно снизить количество аллокаций при работе с потоками (очень часто метод ReadAsync завершается синхронно, как и в примере с MemoryStream).

Однако, и при разработке сервисов с высокой пропускной способностью, в которых асинхронное завершение не редкость, нам нужно всеми силами стараться избегать дополнительных аллокаций.

Как говорилось ранее, в модели async/await, любая операция, которая завершается асинхронно, должна вернуть уникальный объект, для ожидания завершения. Уникальный, т.к. он будет служить каналом выполнения обратного вызова. Отметим, однако, что данная конструкция ничего не говорит о том, можно ли повторно использовать возвращенный объект ожидания, уже после завершения асинхронной операции. Если объект может быть повторно использован, то API может поддерживать пул для такого рода объектов. Но, в таком случае, этот пул не может поддерживать конкурентный доступ — объект из пула будет переходит из состояния «завершен» в состояние «не завершен» и обратно.

Для поддержки возможности работы с такого рода пулами, в .NET Core 2.1 был добавлен интерфейс IValueTaskSource, а структура ValueTask была расширена: теперь объекты этого типа могут оборачивать не только объекты типа TResult или Task, но и экземпляры IValueTaskSource. Новый интерфейс обеспечивает базовый функционал, который позволяет объектам ValueTaskработать с IValueTaskSource в той же манере, что и с Task:

public interface IValueTaskSource
{
    ValueTaskSourceStatus GetStatus(short token);
    void OnCompleted(
        Action