AtomicReferenceFieldUpdater怀疑

Question

I was creating a concurrnetHashtable that is suitable for me and little different from concurrentHashMap, and i am using AtomicReferenceFieldUpdater to make CASNext operation ( usually CAS is supported but by this we can perform CASNext also ), so am i going on right path ? Though usually i get good performance in this concurrentHashTable than locking hashtable, but sometimes things doesn't work out.
So i came to following conclusion :
if number of available processor are greater than number of bucket available in the hashtable then there are higher probability of getting lock contention, so in this case concurrentHashTable is going to work better than locking approach, and ofcourse if reading are much ( journals says 85-90% reading operation) , then it's good for use .. so please suggest me, am i going on the right path, and assuming things correctly ?
if you get time then see code on this page code In this hash table i am doing insertions if element is not present already... so tell me whether this is a correct lock-free approach ?

Answer 1

Not a direct answer, but if you are looking to improve on CHM have a look at the one written by Dr. Cliff Click: here

Apart from that, it's hard to help without knowing what you are trying to solve...

Answer 2

in a concurrent hash map there are 3 major operations to worry about: adding a element, removing an element and rehash

in removing and adding it's easy enough with CaS only

however a rehash will introduce races left and right which can result in data being dropped, elements not being visible for some ops, infinite loops and this is very hard to get right and using r/w locks on the whole table is much easier