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