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

David Holmes david.holmes at oracle.com
Wed May 29 04:00:33 UTC 2013

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

---

More information about the core-libs-dev mailing list