Question about atomicity in ConcurrentHashMap

[Brian Goetz]

This is subtle.

Just as everything else about Map does not make any promises about 
thread-safety or atomicity, computeIfAbsent in Map does not either. 
However, when used in a thread-confined manner, just like anything else 
about a non-thread-safe Map, it still useful and sensible and well-defined.

Just as ConcurrentMap adds additional thread-safety semantics to the 
methods of Map, it adds atomicity to computeIfAbsent.  It is allowable 
for an interface like ConcurrentMap to be stronger than a superinterface 
like Map.

As it turns out, the defaults in Map are carefully written so as to only 
depend on methods that are atomic in ConcurrentMap, so magically when 
inherited by a ConcurrentMap, they are atomic.

On 5/23/2013 11:00 AM, Gernot Neppert wrote:
> Hi,
>
> while testing build 90 of JDK 1.8.0, I was pleased to see that dearly
> missed methods such as 'computeIfAbsent' have now been included in
> interface Map!
>
> However, in the past, whenever I needed such a method, it would have had to
> be atomic in order to be useful.
>
> The JavaDoc of java.util.Map.computeIfAbsent clearly states:
>
> "Any implementation providing atomicity guarantees must override this
> method and document its concurrency properties."
>
> So I'm wondering: Why does ConcurrentHashMap not implement those methods in
> an atomic way?
>