1. Введение

Принцип асинхронного программирования состоит в том, что длительно выполняющиеся (или потенциально длительно выполняющиеся) функции реализуются асинхронным образом. Он отличается от традиционного подхода синхронной реализации длительно выполняющихся функций с последующим их вызовом в новом потоке или в задаче для введения параллелизма по мере необходимости.

Асинхронный подход обеспечивает:

- параллельное выполнение операций ввода-вывода без связывания потоков;

- уменьшение количества кода в рабочих потоках обогащенных клиентских приложений (созвучно с понятием «

Это приводит к двум сценариям использования асинхронного программирования.

Первый сценарий касается серверных приложений, которые обрабатывают множество параллельных операций ввода-вывода. В таких приложениях важна не безопасность потоков (разделяемое состояние минимально), а эффективность их использования, чтобы поток, обрабатывающий клиентские запросы, не простаивал на сетевых операциях.

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

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

Мелкомодульный параллелизм — последовательность небольших параллельных операций, между которыми выполнение возвращается в главный поток пользовательского интерфейса [1]. Например, методы, отвечающие за отражение промежуточных результатов, не требуют значительного времени и могут выполняться в основном потоке, что упрощает потокобезопасность.

Целесообразность применения асинхронного программирования несомненна при работе с операциями ввода-вывода и трудоемкими по времени вычислениями

[2][3]

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

- синхронное завершение асинхронной функции;

- кеширование

- применение структуры

- реализация IValueTaskSource<T>.

2. Синхронное завершение асинхронной функции

Возврат из асинхронной функции может произойти перед организацией ожидания. Рассмотрим следующий код, который обеспечивает кеширование в процессе загрузки веб-страниц:

При ожидании задачи компилятор оптимизирует код, проверяя свойство IsCompleted. Если задача уже завершена (например, при наличии данных в кеше), выполнение происходит с возвратом завершённого экземпляра задачи без создания продолжения. Это называется синхронным завершением. В противном случае создается продолжение для асинхронного выполнения. Такой подход позволяет избежать накладных расходов на асинхронность, когда она не требуется, ускоряя выполнение кода, когда данные доступны немедленно.

В представленном примере ожидание асинхронной функции, которая завершается синхронно, все равно связано с небольшими накладными расходами (компилятор все равно добавляет код для управления состоянием метода и возможным продолжением) — примерно 20 наносекунд на современных компьютерах. Напротив, переход в пул потоков вызывает переключение контекста — возможно одну или две микросекунды, а переход в цикл обработки сообщений пользовательского интерфейса — минимум в десять раз больше (и еще больше, если пользовательский интерфейс занят) [3].

Асинхронное программирование в C# предоставляет интересную возможность: создавать асинхронные методы, которые фактически никогда не используют ключевое слово await. Например, можно написать метод вида:

Хотя компилятор и выдаст предупреждение об отсутствии await, такой код вполне допустим и работоспособен. Альтернативный способ достижения того же результата заключается в использовании метода Task.FromResult, который возвращает уже завершенную задачу. В этом случае метод может выглядеть так:

Этот вариант не требует использования ключевого слова async. Оба подхода позволяют сохранить согласованность интерфейса и обеспечивают гибкость при реализации асинхронных интерфейсов. Они особенно полезны, когда необходимо работать с асинхронным кодом в преимущественно синхронных сценариях. Важно отметить, что в обоих случаях возвращается сигнализированная (завершенная) задача. Когда же метод помечен как async и использует await, компилятор автоматически генерирует состояние машины (state machine) для управления асинхронными операциями. Это включает в себя создание нескольких объектов и структур для управления жизненным циклом задачи, что влечет за собой дополнительные накладные расходы.

Если наш метод

Существует простой способ достичь указанной цели, не прибегая к блокировкам или сигнализирующим конструкциям. Вместо кеша строк мы создаем объект-обещания (

Обратите внимание, что мы не помечаем метод как

Теперь при повторяющихся вызовах метода

[4][5]

Чтобы сделать код безопасным к потокам без защиты со стороны контекста синхронизации, необходимо блокировать все тело метода

[6]

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

3. Кеширование Task

Одной из ключевых концепций в асинхронном программировании является использование класса

[3]

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

[7]

Для иллюстрации рассмотрим следующий пример:

В данном примере, если метод завершается синхронно, ему не нужно возвращать новый

Таким образом, если в методе

Или, например, представим код, в котором метод

Поскольку есть только два возможных результата типа bool(true и false), то существует только два возможных объекта Task, которые нужны для представления этих результатов. В сценарии синхронного завершения среда .NET обеспечивает кеширование этих объектов, возвращая их с соответствующим значением без выделения памяти. Только в случае асинхронного завершения (достигается вызовом RandomWithAsyncDelay с параметром setAsync равным true) методу понадобится создать новый Task, потому что его нужно будет вернуть до того, как станет известен результат операции. Вывод программы при различных значениях параметра setAsync представлен на рисунках 1 и 2.[8]

Множество методов библиотеки стремятся сгладить ситуацию за счет использования собственного кеша. В частности, в .NET Framework 4.5 метод MemoryStream.ReadAsync всегда выполняется синхронно, поскольку он считывает данные из памяти (данный метод можно найти в исходном коде .NET на GitHub [9]).

4. Применение структуры ValueTask

.NET Core 2.0 ввел новый тип

[10][11]

В этом примере, если

Однако при разработке высокопроизводительных сервисов по-прежнему важно минимизировать любое выделение памяти, включая размещения в куче объектов, которые связаны с асинхронными операциями. В .NET Core 2.1 тип

[12][13]

Основные методы

- 

- 

- 

Интерфейс

Проблема повторного использования

Вывод программы:

firstValueTask.Result: Результат #1

firstValueTask.Result: Результат #2

secondValueTask.Result: Результат #2

Структурно представим выполнение вышеуказанного кода:

1. Первый запрос к базе данных:

1.1. Создается объект

1.2. Запускаются два потока, которые ожидают завершения этой операции. Первый поток немедленно выполняет

1.3. Второй поток ожидает завершения

2. Второй запрос к базе данных:

2.1. Тот же объект

2.2. Запускается еще один поток, который асинхронно ожидает завершения второй операции.

Таким образом, второй поток, который ожидает завершения

В представленном коде закомментированная строка:

objPool.token = (

shortEnvironment

играет важную роль в предотвращении проблемы повторного использования экземпляра

Таким образом, возможность повторного использования экземпляра

Когда

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

5. Реализация IValueTaskSource c применением ManualResetValueTaskSourceCore

Реализация интерфейса

[14]

С введением

На рисунке 3 представлен вывод после запуска кода:

Сброс (Reset) очищает все внутренние состояния объекта, такие как захваченные контексты выполнения, продолжения, исключения и результат предыдущей операции. После вызова _core.Reset поле _version будет инкрементировано и свойство _core.Version вернет значение, которое не будет соответствовать первоначальному. Это важно для предотвращения ошибок при многократном ожидании завершения одной и той же задачи. В приведенном выше коде объект из пула был возвращен и повторно использован слишком рано, в то время, когда один из потоков все еще ожидал первоначальный объект.

6. Ограничения на использование ValueTask

Рассмотрим ограничения, нарушение которых может привести к некорректной работе программы, состояниям гонки и другим труднодиагностируемым ошибкам.

Первое – многократное ожидание (

Второе — использование метода

Указанные ограничения определяют важное правило: с экземплярами

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

[15][16]

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

Результаты тестирования реализаций функции Аккермана с применением

[17]

-    процессор Intel Core i5-9300H (8 логических, 4 физических ядра)

-    оперативная память DDR4 16 ГБ,

-    операционная система Windows 11 (10.0.22631.4460),

Runtime=.NET 9.0.3 (9.0.325.11113), X64 RyuJIT AVX2.

- При передаче экземпляра структуры

- 

Адаптация функции Аккермана к интерфейсу IValueTaskSource<T> не дало выигрыша ни в производительности, ни в использовании управляемой памяти, так как использование глубокой рекурсии приводит к переполнению пула объектов.

7. Заключение

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

По итогам проведенного анализа сформированы принципы оптимизации асинхронных операций:

- Выполнение предварительной проверки завершения асинхронной операции и, если результат уже доступен (например, из кеша), обеспечить синхронное завершение метода, чтобы избежать затрат на создание асинхронной инфраструктуры. Использование кешированных задач, таких как

- Применение методов, возвращающих

- Использование структуры

- Реализация механизма управления асинхронными операциями через интерфейс

Результаты тестирования в синхронном сценарии на примере функции Аккермана показали, что при малых аллокациях в памяти целесообразно применение Task<T>, так как данный тип не уступает в производительности ValueTask<T>. В асинхронном сценарии с возвращаемой структурой ValueTask<TResult> положительный результат потенциально достижим с применением интерфейса IValueTaskSource<T> и эффективным использованием пула объектов (т.е. не вызывая его переполнения).

The additional file for this article can be found as follows: