Re: ConcurrentHashMap's clear() may make size() always incorrent

Doug Lea via Concurrency-interest <[email protected]> Sun, 19 Jul 2020 06:49:03 -0400
Newsgroups gmane.comp.java.jsr.166-concurrency
Message-ID <[email protected]>
On 7/18/20 6:01 AM, Liu via Concurrency-interest wrote:
>
>     The reason why sumCount() may return a negative number, is that 
> when sumCount() invoked by clear() just traverse a CounterCell object 
> to get its count, a later delete operation comes and decrease this 
> CounterCell's value. Then addCount(delta, -1) invoked by clear() will 
> add a smaller negative number which is incorrent.

Yes, when clears race with removes, some reported counts may be 
inaccurate. They would be less inaccurate if decrements were performed 
one-by-one, but at noticeable cost. Still, thanks for the reminder that 
this might be improved.

>
>
>   Perhaps correct way is to make baseCount and counterCells all zero.

There is no quiescent point to do this, so this would also race and 
sometimes be inaccurate.

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest