Map.forEach

Martin Buchholz martinrb at google.com
Tue Dec 10 18:15:34 UTC 2013


Perhaps Doug could provide history on the intent of ConcurrentMap.  But
regardless of that, if I actually READ the (jdk7) spec, it pretty much just
says,

A Map <http://docs.oracle.com/javase/7/docs/api/java/util/Map.html> providing
additional atomic putIfAbsent, remove, and replace methods.

i.e. all it provides is atomic read-modify-write access to individual
entries in the map.  ConcurrentMap (in jdk7) is silent on operations that
access more than one entry - nothing about weak consistency or CME.
 Hashtable fits perfectly.

Which further suggests that default methods on Map and ConcurrentMap that
access multiple entries (like forEach) should behave identically.


On Tue, Dec 10, 2013 at 1:06 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On Dec 10, 2013, at 5:14 AM, Martin Buchholz <martinrb at google.com> wrote:
> >
> > Hmmm... it was time that I studied Map.forEach....  I see you convert to
> > ISE to CME ...
> >
> > (Synchronized maps (like Hashtable) do not implement ConcurrentMap.  Is
> > that a bug?)
> >
> > Imagine a third party implementation of a synchronized map (again, like
> > Hashtable).  Its existing methods are synchronized, but in jdk8 it
> inherits
> > Map.forEach (not ConcurrentMap.forEach, because like Hashtable, it does
> not
> > implement ConcurrentMap) and so might throw CME even though its
> > implementation may never throw this and its entrySet may be designed for
> > concurrent traversal.
> >
>
> Are you assuming the iterators of the collection views of the third party
> implementation would be weakly consistent? if so would expect that
> implementation to implement ConcurrentMap.
>
>
> > Another argument - before jdk8, whether a Map also implemented
> > ConcurrentMap was mostly symbolic, and could not affect behavior.  Users
> > could add "implements ConcurrentMap" purely for its documentation value.
> > Where possible, we should try to preserve that property.
> >
> > Oh, and seriously, should Hashtable implement ConcurrentMap today?  It
> > appears to implement all of its methods in a thread-safe way.
>
> Not sure Hashtable should implement ConcurrentMap.
>
> While the Hashtable methods are synchronized the collection views will
> fail fast on modification (one of the few cases where CME is explicitly
> used with concurrent access in mind :-) ). Although it is not explicitly
> called out I think the likely expectation is (well, my expectation is) that
> a ConcurrentMap provides weakly consistent iterators.
>
> Paul.
>



More information about the core-libs-dev mailing list