Question about atomicity in ConcurrentHashMap

[Jonathan Gibbons]

On 05/23/2013 08:33 AM, Brian Goetz wrote:
> 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.

Perhaps that should be documented as part of the spec.

-- Jon


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