- 1
- 2
- 3
Нужно реализовать thread-safe set.
На сколько нормально разбить сет на N бакетов (по хешу, условно, 10000 штук),
тогда при добавлении или удалении элемента делать лок соответствующего бакета
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
Нужно реализовать thread-safe set.
На сколько нормально разбить сет на N бакетов (по хешу, условно, 10000 штук),
тогда при добавлении или удалении элемента делать лок соответствующего бакета
Но будет хуево, когда пойдут запросы по одному ключу в нескольких тредах.
Есть решение лучше?
bormand 12.05.2021 15:04 # +3
Ну это уже неизлечимая проблема, как мне кажется, если они реально к одному ключу лезут... По крайней мере большую часть пересечений ты таким разбиением убрал.
З.Ы. В джаве вроде такая реализация и есть.
booratihno 12.05.2021 15:20 # 0
если ты пишешь раз в год, а читаешь раз в ms, то будет хорошо
bormand 12.05.2021 15:24 # +1
... то можно вообще не париться и юзать иммутабельные структуры. Один атомик на чтение корня и дальше вообще насрать на конкуренцию.
PolinaAksenova 12.05.2021 15:11 # +3
https://github.com/zhangshun97/Lock-free-Red-black-tree
CHayT 12.05.2021 16:27 # +1
j123123 12.05.2021 21:10 # +1
bormand 13.05.2021 08:29 # 0
Ага, там по-моему 99% статей про локфри в духе "они вот тут обосрались, но мы пофиксим это вот так"...
Я даже не знаю, в итоге есть какая-нибудь формально корректная реализация?
guest6 12.05.2021 15:14 # +2
позырь тут
https://www.baeldung.com/lock-free-programming
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html
guest6 12.05.2021 15:22 # +1