RFR 8005704: Update ConcurrentHashMap to v8 (original) (raw)

David Holmes david.holmes at oracle.com
Wed May 29 08:40:29 UTC 2013

On 29/05/2013 2:29 PM, Martin Buchholz wrote:

On Tue, May 28, 2013 at 9:00 PM, David Holmes <david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> wrote: On 29/05/2013 5:53 AM, Martin Buchholz wrote:

Is atomicity part of the contract of ConcurrentMap.getOrDefault? Currently, it doesn't say. Actually, there are two possible guarantees it could make - whether the default implementation ConcurrentMap.getOrDefault is atomic (when the map does not accept nulls) and whether subclasses that override getOrDefault must make this guarantee.

I want to re-examine the new methods that ConcurrentMap is inheriting from Map because I think more statements regarding concurrency properties are required. This included getOrDefault even though overridden. Agreed. --- Curiously, ConcurrentMap doesn't guarantee that get() is atomic. Perhaps it should? Only composite operations (those that could expressed as a sequence of other operations) need an atomicity guarantee. Operations like get() simply need to be thread-safe. You're right. Let me rephrase: Curiously, ConcurrentMap doesn't guarantee that get() is thread-safe, or that a ConcurrentMap can be used from multiple threads. Perhaps it should?

Right. I find this:

rather lacking looking at it today. First the list needs updating - though it was suggested by Doug that we stop listing the methods and simply make a general statement. Somewhat disturbingly I now see that some of the new Map methods may not in fact be "atomic".

Second it says nothing about thread-safety. The only reference to thread-safety is in the j.u.c package-info docs:

" A concurrent collection is thread-safe, but not governed by a single exclusion lock."

I went back to my email archives from when we put this altogether back in 2002/2003 and I found no reference to ever actually saying in ConcurrentMap that the Map was thread-safe. This may in part be because what we called ConcurrentMap simply started out as an interface in which to put putIfAbsent and we really only cared about the fact that ConcurrentHashMap would implement it - and we couldn't call it Map.

David

More information about the core-libs-dev mailing list