[concurrency-interest] ConcurrentHashMapV8

Dr Heinz M. Kabutz heinz at javaspecialists.eu
Fri Dec 23 09:36:25 EST 2011


I would like to run some performance tests comparing CHMv8 to the CHM in 
Java 7 and to Cliff Click's non-blocking hash map implementation.  
However, I do not have access to hardware that will do the test 
justice.  Would any of you be able to run some tests for me on machines 
in excess of 50 cores?  The more the better.  If so, please contact me 
directly.

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 72 850 460
Skype: kabutz 



On 10/7/11 1:41 PM, Doug Lea wrote:
> On 10/06/11 17:39, David M. Lloyd wrote:
>> -- we add some
>>> time/space overhead to entrySet operations just to imperfectly
>>> reinforce the questionable intuition that methods operate
>>> directly on internal Entry objects that don't actually exist
>>> (and need not actually exist wrt any other aspects of Map specs).
>>
>> But if the Entry actually *did* reflect the actual physical entry, 
>> then the
>> contract for the Entry interface makes a lot more sense. You can 
>> retrieve the
>> key always, and the value if it hasn't been removed (if it has you 
>> could give
>> IllegalStateException as is allowed by spec).
>
> We considered and rejected this approach back in JDK5 when deciding
> upon iterator semantics for concurrent collections. If you allow
> hasNext() to lie, claiming that an element exists but then throwing
> an exception in next() because it no longer exists, then most
> client iterator usages break. So instead we ensure that if
> hasNext saw a valid element, then it is snapshotted as the one
> returned in next(). Since these elements can concurrently come
> and go at any time, receiving this (weakly consistent) snapshot
> is as much as you can expect anyway. Even if you exported
> a "live" entry, it could disappear as soon as client reads it
> but before it acts upon it.
>
> The underlying problem is that the non-atomic hasNext()/next()
> pairing in Iterator is inherently concurrency-hostile.
> But we didn't want to replace it with something else.
> However, with upcoming lambdas and bulk operations, I'm
> considering creating a variant of CHM that does not support
> iterators at all, but instead several variants of
> method forEach(entry -> action) etc.
>
> -Doug
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


More information about the Concurrency-interest mailing list