> IMHO, it can be fixed by making HashEntry.value a
> volatile member.
Yes, this is what we'll do. Even though it is overkill,
it makes it more obviously correct wrt the memory model.
And with a few other minor tweaks can be done in a way
that doesn't slow anything down noticeably.
> Please note that one can get
> map.entrySet().iterator(), and directly change objects
> there. Since there is no lock on HashEntry.setValue(),
> it must be, at least, volatile member.
Digression: ConcurrentHashMap was originally designed to be a drop-in
replacement for Hashtable, possibly even to replace Hashtable in
JDK1.5 (which we ended up not doing). Among Hashtable's quirks is
that iterator.setValue is unsynchronized. But it probably does no one
any good to preserve this quirk in ConcurrentHashMap.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT