On Tue, May 28, 2013 at 9:00 PM, David Holmes <[email protected]>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?
