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