Comments 11
Простите, что докапываюсь до слов, а не содержимого, но очередь точно конкурентная, а не потокобезопасная или многопоточная? Если в английском concurrent (одновременный) тут применимо, то созвучное русское слово ну вообще же не в тему. Это не прямой перевод, не устоявшийся в русском термин.
Полностью согласен и ещё добавлю - слова синхронный и concurrent не противоположные, так как concurrent тоже выполняется синхронно (вызывающий код ждёт). То есть, даже слово "синхронный" в статье используется неверно. Лучше писать "однопоточный" или ещё как-то.
Слово "синхронный" в данном контексте я использовал как синоним "блокирующий". Он не имеет отношения к асинхронности. Согласен, что плохой синоним.
На счет "конкурентная" - в данном случае, используется для обозначения поддержки одновременных операций несколькими потоками. Лучше подходит синоним "потокобезопасный", но использовал "конкурентный", т.к. сам класс назвал в соответствии с наименованием многопоточных структур данных из стандартной библиотеки (из пространства имен System.Collections.Concurrent, все они имеют приставку Concurrent)
Просто "concurrent" даже в топ-6 гуглопереводов не переводится как "конкуретный" :)
Ваш "конкурентный" вариант тоже блокирующий. Так что он тоже синхронный.
Как уже написал первый комментировавший, "конкурентный" - плохой и неверный перевод слова "concurrent" в программировании, хотя и упорно продвигается некоторыми.
А Вы не сравнивали с их реализацией? они дают на нее в статье ссылку.
Правда, их статья десятилетней давности, а код последний раз обновлялся 5 лет назад. Ну и всегда можно напрямую автору написать, у Линдена есть профиль на линкедине
Немного не в тему, но всё-же: а пробовали сравнивать производительность SpinLock и Monitor?
К моему удивлению, Monitor работает быстрее, по крайней мере в случаях, когда в основном ему не приходится блокировать поток(и).
Честно говоря, считал, что СпинЛок должен быть гораздо дешевле и шустрее.
На DotNext есть отличная лекция по этой теме. Станислав Сидристый — lock(_sync): иллюзия идеального выбора
Спасибо за ссылку, о паре нюансов даже не задумывался.
Но всё это не отменяет моего удивления: мой случай идеален для SpinLock: очень короткая операция, количество потоков меньше количества ядер, очень низкий или нулевой contention — казалось бы, почему Monitor/Lock заметно лучше? Если бы было +- одинаково — не было бы вопросов.
… по следам этого доклада, прогнал бенчмарк для new SpinLock(false): быстрее дефолтного, но в случае с (около)нулевым контеншном всё равно медленнее lock'a, в случае с высоким контеншном — быстрее.
Позор, конечно, что я упускал это раньше.
У меня была зада с разных потоков собирать счётчики, группировать их, суммировать ща Н времени. При попытке использовать concurrentqueue процессор взлетел под 90 - потому что использует лок. При использовании akka.net никаких проблем с производительностью - все считаетс, процессор отдыхает. И все при одинаковых исходных данных.
Конкурентная очередь с приоритетами (неудачно)