#java #locking #cas #lock-free
#java #блокировка #cas #без блокировки
Вопрос:
Я создавал concurrnetHashtable, который подходит для меня и немного отличается от ConcurrentHashMap, и я использую AtomicReferenceFieldUpdater для выполнения операции CASNext (обычно поддерживается CAS, но с помощью этого мы можем также выполнить CASNext), так что я иду по правильному пути? Хотя обычно я получаю хорошую производительность в этой concurrentHashTable, чем в locking hashtable, но иногда что-то не получается.
Итак, я пришел к следующему выводу:
если количество доступных процессоров больше, чем количество сегментов, доступных в хэш-таблице, то существует более высокая вероятность возникновения конфликта блокировок, поэтому в этом случае concurrentHashTable будет работать лучше, чем подход с блокировкой, и, конечно, если чтения много (в журналах указано 85-90% операций чтения), тогда это полезно для использования .. поэтому, пожалуйста, подскажите мне, я иду по правильному пути и предполагаю, что все правильно?
если у вас будет время, посмотрите код на этой странице code В этой хэш-таблице я делаю вставки, если элемент еще не присутствует… итак, скажите мне, правильный ли это подход без блокировок?
Комментарии:
1. вместо этого вы могли бы дать несколько полезных советов здесь…
2. Можете ли вы опубликовать код? С нашей хэш-таблицей без блокировок нам пришлось создать тестовый пример, в котором многие потоки ничего не делают, кроме добавления / удаления элементов, прежде чем возникнет хотя бы пара процентов коллизий. Даже если нам придется переделывать из-за коллизии, нам понадобится что-то сумасшедшее, например, 50%-ная скорость повтора, прежде чем производительность снизится настолько, что lockign станет лучше. Итак, что вы делаете, что может привести к этому?
Ответ №1:
Это не прямой ответ, но если вы хотите улучшить CHM, взгляните на тот, который написан доктором Клиффом, Нажмите: здесь
Кроме того, трудно помочь, не зная, что вы пытаетесь решить…
Ответ №2:
в параллельной хэш-карте есть 3 основные операции, о которых следует беспокоиться: добавление элемента, удаление элемента и повторное хэширование
при удалении и добавлении это достаточно просто только с CAS
однако перефразирование приведет к скачкам влево и вправо, что может привести к удалению данных, отсутствию элементов для некоторых операций, бесконечным циклам, и это очень сложно исправить, а использование r / w блокировок для всей таблицы намного проще
Комментарии:
1. приведите некоторые представления об этом AtomicReferenceFieldUpdater… обновляет ли эта операция также ссылку атомарно (она должна, как следует из названия .. ), поэтому, если ConcurrentHashMap мне не подходит, и я создал свою concurrentHashTable, используя AtomicReferenceFieldUpdater , она должна работать правильно, верно? обеспечивает лучшую производительность, чем блокировка?
2. если цикл CaS (то, что выполняется между получением данных и выполнением CAS) велик, существует опасность сбоя в этой операции, хэш-карты просто не подходят для этого (и нужно учитывать множество рас)