Я долгое время был большим поклонником System.Collections.Concurrent и BlockingCollection, в частности.
Я не могу сосчитать, сколько раз это чудо техники выручало в самых разных ситуациях.
С несколько менее древних времен async/await прочно вошёл в употребление.
Казалось бы, жизнь прекрасна, но есть одно «но»: смешивать асинхронный код с блокирующим кодом как-то не очень хочется.
А BlockingCollection, как можно догадаться (по крайней мере, из названия), в некоторых случаях блокирует поток.
Ложный след: Nito.AsyncEx
Однажды я наткнулся на ссылку на библиотеку Нито.AsyncEx
Стивена Клири, в котором был класс с интригующим названием AsyncCollection. Однако, взглянув на то, что было под капотом, я остался в некотором недоумении: там был AsyncLock из той же библиотеки, прикрепленный ко всем действиям над обернутой IProducerConsumerCollection. AsyncLock, в свою очередь, активно использует самые обычные блокировки и тонкий слой магии, разгадывать который мне вдруг не захотелось.Даже если эта реализация и делает то, что заявлена, она выглядит немного надуманной, чудовищной и, возможно, не очень оптимальной.
Неужели нельзя точнее решить эту задачу? Мы все знаем последствия таких мыслей.
Visual Studio, Новый проект…
Асинккуеу
Для начала давайте определимся, чего мы вообще хотим от нашей асинхронной коллекции.В качестве отправной точки можно взять следующий интерфейс: Теги: #C++ #.
NET #async #await #асинхронные коллекции #interlocked #dependent #memorybarrier #magic #.
NET #C++ #Параллельное программирование
-
Использование Карты «Тройка» Как Полиса Омс
19 Oct, 24 -
Песочница В Windows
19 Oct, 24 -
Колонизация Галактик
19 Oct, 24 -
Альянс По Борьбе С Заблуждениями В Сми
19 Oct, 24 -
Мужской Мозг Лучше Всего Работает В 39 Лет
19 Oct, 24
