[concurrency-interest] ConcurrentHashMap footprint and contention improvements
fry at google.com
Thu Apr 21 08:49:20 EDT 2011
In your current containsValue implementation it looks like the type and the
name of the hashSum and sum variables (respectively) should be combined into
'long sum = 0L'.
It still seems that initializing last to -1L would avoid the need to check
retries > 0.
On Fri, Apr 15, 2011 at 19:10, Doug Lea <dl at cs.oswego.edu> wrote:
> On 04/15/11 14:16, Martin Buchholz wrote:
>> Taking another look, it appears that if we have an existing key k,
>> then put(k,v) (or corresponding entry.setValue(v)) will affect neither
>> the segment modcount (only insertions and deletions do that) or the
> Yes, good point (this was also a problem with existing version).
> This requires modCount updates on existing-put and replace.
> Which together with other changes argue for again
> relying solely on modCounts in containsValue. (Also, size()
> is now slightly more prone to unnecessary retries but almost
> surely not measurably.) These changes are now committed to CVS.
> As another aside to other readers: Other j.u.c maps
> do not make as strong a guarantee about the atomicity of
> containsValue, and there is a good argument for not doing so.
> However, we originally did it this way for ConcurrentHashMap,
> and should not change it now; mainly because it is such a
> rarely used method (and even rarer still used when value
> is not present but table is undergoing modifications) that
> it is not worth changing specs to allow it to run a bit
> faster; especially since even at its fastest, it is still
> intrinsically O(n).
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest