Question about atomicity in ConcurrentHashMap
jonathan.gibbons at oracle.com
Thu May 23 08:53:09 PDT 2013
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.
> On 5/23/2013 11:00 AM, Gernot Neppert wrote:
>> 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?
More information about the lambda-dev