RFR 8005704: Update ConcurrentHashMap to v8

[David Holmes]

Martin,

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.

> ---
>
> 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.

Actually I think we have wandered off-track a little with the use of 
"atomic" in these API's. To say that a method is "atomic" is pretty 
meaningless for most map methods. Where it gets meaning is when we say 
that an operation, like putIfAbsent, acts "as-if xxxx then yyyy, except 
that it is performed atomically".

David
-----


> ---
>