[concurrency-interest] ConcurrentHashMap entrySet Iterator remove issue?

Doug Lea dl at cs.oswego.edu
Sat Feb 6 15:54:38 EST 2016


On 02/05/2016 09:05 PM, Martin Buchholz wrote:
> It's not entirely clear whether entrySet().iterator().remove() should
> remove the entry for the current key or only if still mapped to the
> old value.  But acting like the latter seems better for users - I
> agree with Mike.  The existence of map.remove(K, V) gives an
> expectation that iterator().remove() works likewise.

As others have mentioned, iterator.remove is underspecified, so
either behavior is allowed. In general it is a bad idea to use
it in a concurrent program if you care about outcome -- instead use
the version of map.remove that you need/want.

> The counter-arguments against switching now are:
> - it is a small added implementation burden for the iterator to keep
> track of the old value, that will almost never be used.
> - users can just call remove(K, V) - they have the old v in hand, that
> the map has already forgotten.
> - status quo wins whenever there's doubt!
>
> But the behavior should be documented.

Or perhaps the uncertainty of effect should be documented in
the ConcurrentMap interface, since the issue occurs with
all ConcurrentMaps?

-Doug




More information about the Concurrency-interest mailing list