On Dec 10 2013, at 01:06 , Paul Sandoz <[email protected]> wrote:
> On Dec 10, 2013, at 5:14 AM, Martin Buchholz <[email protected]> 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. This observation suggests that we should describe this characteristic in the ConcurrentMap specification. > > >> 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. I agree that the iterator behaviour for Hashtable (and of Collections.synchronizedMap) falls short of what one would expect of a ConcurrentHashMap. Mike
