On 29/05/2013 2:29 PM, Martin Buchholz wrote:
On Tue, May 28, 2013 at 9:00 PM, David Holmes <[email protected]
<mailto:[email protected]>> wrote:
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.
Agreed.
---
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.
You're right. Let me rephrase:
Curiously, ConcurrentMap doesn't guarantee that get() is thread-safe, or
that a ConcurrentMap can be used from multiple threads. Perhaps it should?
Right. I find this:
* A {@link java.util.Map} providing additional atomic
* {@code putIfAbsent}, {@code remove}, and {@code replace} methods.
rather lacking looking at it today. First the list needs updating -
though it was suggested by Doug that we stop listing the methods and
simply make a general statement. Somewhat disturbingly I now see that
some of the new Map methods may not in fact be "atomic".
Second it says nothing about thread-safety. The only reference to
thread-safety is in the j.u.c package-info docs:
" A concurrent collection is thread-safe, but not governed by a single
exclusion lock."
I went back to my email archives from when we put this altogether back
in 2002/2003 and I found no reference to ever actually saying in
ConcurrentMap that the Map was thread-safe. This may in part be because
what we called ConcurrentMap simply started out as an interface in which
to put putIfAbsent and we really only cared about the fact that
ConcurrentHashMap would implement it - and we couldn't call it Map.
David
