Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, artelk, Вы писали:

A>>А чем таски тежеловесны? Слишком много полей? Методы слишком много делают?
V>...
V>Еще часто оперируют TLS-хранилищем, перетасовывая стек ExecutionContext, что например, порой требует даже постоянной переустановки культуры текущему потоку перед каждым чихом.
V>(в нейтиве культура привязана к "физическому потоку", то бишь потоку уровня ОС, а в дотнете — к логическому).
ExecutionContext хранит AsyncLocals, не хотелось бы их потерять.


V>В общем, использовать ValueTask — экономить на спичках.
ValueTask оптимизирует случай, когда задача завершена синхронно и он позволяет избежать создания объекта Task в куче. Для этого и создан.


A>>SemaphoreSlim работает как FIFO (правда, это свойство не отраженов документации, но лучше бы его воспроизвести).
V>ХЗ.
V>В недрах ОС базовая очередь потоков одинакового приоритета к ресурсу всегда FIFO.
V>Отличия от FIFO чаще являются светошумовыми эффектами разных приоритетов, например, при инверсии приоритетов, когда низкоприоритетному потоку дают больше квантов времени, чем его соседям по приоритету, чтобы он освободил ресурс для высокоприоритетного потока.
Не понял причем тут очередь потоков.

V>В SemaphoreSlim эта логика дополнительно усложняется тем, что он может работать и как обычный синхронный семафор, т.е. одно только убирание синхронной функциональности упрощает алгоритмы блокировок.
+1

V>В общем, навскидку сложно сказать, насколько это будет дешевле обычной сериализации доступа через мьютекс (критическую секцию) к состоянию асинхронного семафора, ведь в случае оперирования более легковесными чем Task объектами эта блокировка будут весьма короткой, т.е. вероятность столкновения на ней будет мала.
Это ты об операции добавления в очередь пишешь? Не понятно как к этому относится тяжеловесность\легковесность объектов Task или их аналогов.


A>>И от объектов в куче мы не избавились — мы массивы создаем.
V>Я бы ограничился одним массивом.
V>В реальной жизни конкурентность к ресурсу обычно невысока — от силы десятки или единицы сотен "заявок".
Как одним? Давая обясню проблему, которую я имел ввиду. Вот вызвал клиент WaitAsync и получил назад MyValueTask. Далее он может его сохранить где-то у себя и проверить у него свойство IsCompleted через час. И значение должно быть верным. Т.е. элемент массива должен быть прибит гвоздями к своему "владельцу" MyValueTask и не может быть переиспользован даже если последний давно стал Complete.