RFR 8005704: Update ConcurrentHashMap to v8

[David Holmes]

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:

  * A {@link java.util.Map} providing additional atomic
  * {@code putIfAbsent}, {@code remove}, and {@code replace} methods.

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