RFR 8005704: Update ConcurrentHashMap to v8 (original) (raw)

Martin Buchholz martinrb at google.com
Wed May 29 04:29:20 UTC 2013

On Tue, May 28, 2013 at 9:00 PM, David Holmes <david.holmes at oracle.com>wrote:

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

More information about the core-libs-dev mailing list