{"draftJsState":{"blocks":[{"data":{"image":{"id":"65cda4723beadd505a82b87c"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"94f51"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"ValueTasks","type":"header-two","key":"da9pt"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Task по сей день продолжает оставаться рабочей лошадкой асинхронности в .NET, при этом новые методы открываются в каждом выпуске и регулярно во всей экосистеме, которые возвращают Task-и Task. Однако Task это класс, а это означает, что его создание требует выделения памяти. По большей части одно дополнительное выделение для долгоживущей асинхронной операции — это гроши, которые не окажут существенного влияния на производительность всех операций, кроме наиболее чувствительных к производительности. Однако, как было отмечено ранее, синхронное завершение асинхронных операций встречается довольно часто. Stream.ReadAsync был введен для возврата a Task, но если вы читаете, скажем, в BufferedStream, есть очень большой шанс, что многие из ваших операций чтения будут завершены синхронно из-за просто необходимости извлекать данные из буфера в памяти, а не выполнять системные вызовы и настоящий ввод-вывод. Необходимость выделять дополнительный объект только для возврата таких данных является не лучшим решением (обратите внимание, что это было и в случае с APM). Для неуниверсальных Task методов, возвращающих метод, метод может просто возвращать одноэлементную уже выполненную задачу, и фактически один такой синглтон предоставляется Task в форме Task.CompletedTask. Но для Taskневозможно кэшировать Task для всех возможных TResult. Что мы можем сделать, чтобы ускорить такое синхронное завершение?","type":"unstyled","key":"3g2no"},{"data":{},"depth":0,"entityRanges":[{"key":0,"length":33,"offset":651}],"inlineStyleRanges":[{"length":9,"offset":17,"style":"ITALIC"}],"text":"Можно кэшировать некоторые Task файлы. Например, Taskочень распространено, и там можно кэшировать только две значимые вещи: a, Taskкогда Result true и одна, когда Result false. Или, хотя мы не хотели бы пытаться кэшировать четыре миллиарда Taskзначений для размещения всех возможных Int32 результатов, небольшие Int32 значения очень распространены, поэтому мы могли бы кэшировать некоторые из них, скажем, от -1 до 8. Или для произвольных типов — default это достаточно распространенное значение , чтобы мы могли кэшировать Task где Result находится default(TResult) для каждого соответствующего типа. И фактически, Task.FromResultделает это сегодня (начиная с последних версий .NET), используя небольшой кеш таких многоразовых Taskсинглтонов и возвращая один из них, если это необходимо, или иным образом выделяя новый Taskдля точного предоставленного значения результата. Другие схемы могут быть созданы для обработки других достаточно распространенных случаев. Например, при работе с Stream.ReadAsync, достаточно часто вызывать его несколько раз в одном и том же потоке, все с одинаковым количеством байтов, разрешенных для чтения. И довольно часто реализация может полностью удовлетворить этот запрос. Это означает, что достаточно часто Stream.ReadAsync неоднократно возвращать одно и то же int значение результата. Чтобы избежать множественных выделений в таких сценариях, несколько Stream типов (например, MemoryStream) будут кэшировать последний Task успешно возвращенный результат, и если следующее чтение также завершится синхронно и успешно с тем же результатом, оно может просто вернуть то же самое Task снова, а не создавать новое. А как насчет других случаев? Как можно избежать этого распределения для синхронных завершений в более общем плане в ситуациях, когда накладные расходы на производительность действительно имеют значение?","type":"unstyled","key":"790am"},{"data":{},"depth":0,"entityRanges":[{"key":1,"length":54,"offset":69},{"key":2,"length":19,"offset":278}],"inlineStyleRanges":[],"text":"Вот тут-то и ValueTask появляются на сцене ( также доступно гораздо более подробное исследованиеValueTaskValueTask ). Начал свою жизнь как дискриминационный союз между a TResult и a Task. В конце концов, не обращая внимания на все навороты, вот и все, что есть (или, скорее, было), либо немедленный результат, либо обещание результата в какой-то момент в будущем:","type":"unstyled","key":"7vh6d"},{"data":{"image":{"id":"65cda4c7fda6df2ef77917f1"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"b644h"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Тогда метод мог бы вернуть ValueTaskвместо Taskи за счет большего типа возвращаемого значения и немного большей косвенности избежать выделения, Taskесли TResult было известно к моменту, когда его нужно было вернуть.","type":"unstyled","key":"1v626"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Однако существуют супер-пупер сценарии с экстремально высокой производительностью, в которых вы хотите избежать выделения Taskдаже в случае асинхронного завершения. Например, Socket находятся в нижней части сетевого стека, а SendAsync сокеты ReceiveAsync находятся на очень горячем пути для многих служб, при этом очень распространены как синхронные, так и асинхронные завершения (большинство отправок завершаются синхронно, а многие получают синхронно из-за данных). уже буферизованы в ядре). Разве не было бы неплохо, если бы для данного Socket, мы могли бы сделать такие отправку и получение свободными от выделения памяти, независимо от того, выполняются ли операции синхронно или асинхронно?","type":"unstyled","key":"6p335"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вот тут-то System.Threading.Tasks.Sources.IValueTaskSourceи появляется картина:","type":"unstyled","key":"231b7"},{"data":{"image":{"id":"65cda4e03beadd505a8338f5"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"2fkol"},{"data":{},"depth":0,"entityRanges":[{"key":3,"length":19,"offset":326}],"inlineStyleRanges":[],"text":"Интерфейс IValueTaskSourceпозволяет реализации предоставить собственный объект поддержки для объекта ValueTask, позволяя объекту реализовывать такие методы, как GetResult получение результата операции и OnCompleted подключение продолжения операции. При этом в его определение ValueTask было внесено небольшое изменение : его Task? _task поле было заменено полем object? _obj:","type":"unstyled","key":"4gnib"},{"data":{"image":{"id":"65cda506b88df568a1e8d002"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"6s02"},{"data":{},"depth":0,"entityRanges":[{"key":4,"length":6,"offset":692}],"inlineStyleRanges":[],"text":"Хотя _task поле было либо Task либо null, _obj теперь оно также может быть IValueTaskSource. Как только объект Taskпомечен как завершенный, все, он останется завершенным и никогда не вернется в незавершенное состояние. Напротив, реализация объекта IValueTaskSource имеет полный контроль над реализацией и может свободно двунаправленно переходить между завершенным и неполным состояниями, поскольку ValueTaskконтракт заключается в том, что данный экземпляр может быть использован только один раз, поэтому по конструкции он не должен наблюдать сообщение - изменение потребления в базовом экземпляре (вот почему существуют правила анализа, такие как CA2012 ). Затем это позволяет использовать такие типы, как Socket объединение IValueTaskSourceэкземпляров для повторных вызовов. Socket кэширует до двух таких экземпляров, один для чтения и один для записи, поскольку в случае 99,999% одновременно выполняется не более одного приема и одной отправки.","type":"unstyled","key":"9bk6d"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Я упомянул ValueTask, но нет ValueTask. Когда речь идет только об отказе от выделения памяти для синхронного завершения, необобщенные операции ValueTask(представляющие операции без результатов void) не приносят особого выигрыша в производительности, поскольку одно и то же условие можно представить с помощью Task.CompletedTask. Но как только мы позаботимся о возможности использовать базовый объект, который можно использовать в пуле, чтобы избежать выделения памяти в случае асинхронного завершения, это также имеет значение и для необобщенных объектов. Таким образом, когда IValueTaskSourceбыл введен, также были IValueTaskSourceи ValueTask.","type":"unstyled","key":"fbnos"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":276,"style":"ITALIC"},{"length":5,"offset":283,"style":"ITALIC"}],"text":"Итак, у нас есть Task, Task, ValueTask, и ValueTask. Мы можем взаимодействовать с ними различными способами, представляя произвольные асинхронные операции и подключая продолжения для обработки завершения этих асинхронных операций. И да, мы можем сделать это до или после завершения операции.","type":"unstyled","key":"cpm54"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"ITALIC"}],"text":"Но … эти продолжения по-прежнему являются обратными вызовами!","type":"unstyled","key":"en3nj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Мы по-прежнему вынуждены использовать стиль передачи продолжения для кодирования нашего асинхронного потока управления!","type":"unstyled","key":"eo13n"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Как это исправить????","type":"unstyled","key":"fqt6o"},{"data":{},"depth":0,"entityRanges":[{"key":5,"length":8,"offset":0}],"inlineStyleRanges":[],"text":"Источник to be continued...","type":"unstyled","key":"f5oc3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"marker","key":"FwWoojVaZK7oEn0vaaly"}],"entityMap":{"0":{"data":{"url":"https://github.com/dotnet/runtime/blob/81977309048600e67fdb44a7d4c99aaad89846d7/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs#L5222-L5273"},"mutability":"MUTABLE","type":"LINK"},"1":{"data":{"url":"https://devblogs.microsoft.com/dotnet/understanding-the-whys-whats-and-whens-of-valuetask/"},"mutability":"MUTABLE","type":"LINK"},"2":{"data":{"url":"https://github.com/dotnet/corefx/blob/d6173e069a9bcedfdfd7f4f41e67d23f67157b61/src/System.Threading.Tasks.Extensions/src/System/Threading/Tasks/ValueTask.cs#L53-L58"},"mutability":"MUTABLE","type":"LINK"},"3":{"data":{"url":"https://github.com/dotnet/runtime/blob/81977309048600e67fdb44a7d4c99aaad89846d7/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/ValueTask.cs#L465-L468"},"mutability":"MUTABLE","type":"LINK"},"4":{"data":{"url":"https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca2012"},"mutability":"MUTABLE","type":"LINK"},"5":{"data":{"href":"https://devblogs.microsoft.com/dotnet/how-async-await-really-works/","url":"https://devblogs.microsoft.com/dotnet/how-async-await-really-works/"},"mutability":"MUTABLE","type":"LINK"}}},"mentions":[]}