RFR 8005704: Update ConcurrentHashMap to v8
david.holmes at oracle.com
Wed May 29 04:00:33 UTC 2013
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".
More information about the core-libs-dev