Не всегда. Зависит от настроек семафора
В async методах lock это зло
Зависит от внешнего кода. В данном случае неясно как семафор связан с pool
Это для вчерашнего вопроса, оказалось что в .net standard 2.0 нет каналов, так что выбрал семафоры
https://www.nuget.org/packages/Bmbsqd.AsyncLock/
https://www.nuget.org/packages?q=lock+async
И зачем здесь асинхронный метод?
Потому что нужно весь код писать асинхронно(!)
А потом на каждый вызов метода писать await 😊
https://t.me/DotNetRuChat/1020432
зачем лок, если уже семафором вроде как управляется всё?
Это я только перепутал аккаунт)
https://www.nuget.org/packages/System.Threading.Channels
По этому и решил спросить😂
причём разу два семафора
Один для добавления, второй для получения
Вроде каналы реализованы через queue и самафоры, нет?
а где он блочится?
на будущее, если чего-то нет в нетстандарте или базовой либе - не конец света :D
ну я не смотрел, но возможно, а ты хочешь повторить для себя?
Спасибо, только вот чет не хочется зависимости тянуть, если и через семафоры можно
😂😂, попробую мб переписать на каналы
Куда скинуть на лечение?
Сама архитектура лишняя)
И почему же?
ConcurrentObjectPool должен наследоваться от bjectPool
Копипасти с гитхаба код. Кхъ
Хотя видимо разработчики go на таких и рассчитывали, вот и запихнули каналы прямо в синтаксис языка
Обсуждают сегодня