Comments on: "Copy-on-Iterate" Java Idiom considered broken

By: ckbe

ckbe — Thu, 29 Jul 2010 11:57:52 +0000

Well the only upside of a copy is that you get a snapshot of the CHM at one point in time.

But this idea of an snapshot isn't really supported by the CHM.

So best is, not use a CHM or use it's iterator an be aware, that the iterator returns Objects that have been in the CHM between construction of the iterator and the end of the loop.

By: ron

ron — Thu, 29 Jul 2010 01:32:30 +0000

I do not see the need for any copying here, after all it is a CHM we are working on. As the doc says:

"The view's iterator is a "weakly consistent" iterator that will never throw ConcurrentModificationException, and guarantees to traverse elements as they existed upon construction of the iterator, and may (but is not guaranteed to) reflect any modifications subsequent to construction."

So i won't have any trouble directly iterating on modifiableToEntry.values(). Of course, the above implies, that the underlying collection might get modified during iteration, which might have implications on application logic, but it will not throw any Exception.

Basically this means that if an entry is inserted or removed at a segment or index in the CHM which the iterator has already seen, nothing happens. If an entry is inserted or removed at a segment or index in the CHM which the iterator has not seen yet, the iterator will just deliver the new entry (or not deliver a removed entry).

I also want to mention, that Collections.synchronizedCollection does not provide a synchronized iterator() method, either. The user has to manually synchronize iterator creation, which, as opposed to CHM, is easily possible by syncronizing on the Collection itself (or providing a mutex in the Collections.synchronizedCollection call)

By: Jevgeni Kabanov

Jevgeni Kabanov — Wed, 28 Jul 2010 03:37:52 +0000

In this case the underlying collection is assumed to be synchronized, so toArray() is also synchronized and isn't exposed to anything.

By: Andrey

Andrey — Wed, 28 Jul 2010 01:43:14 +0000

I meant reading/modifying :)
Any way what for to copy the collection values? why not to iterate directly over CHM?

By: ckbe

ckbe — Wed, 28 Jul 2010 01:21:34 +0000

Easiest fix would be:
Use a Collections.synchronizedMap(modifiableToEntry) and a synchronized(modifiableToEntry) {} block round the ArrayList Constructor.

By: ckbe

ckbe — Wed, 28 Jul 2010 01:16:14 +0000

Not that easy. Each and every use (modification or read) of the ConcurrentHashMap must then be synchronized, since the CHM doesn't use itself as a mutex. And then you got a “NonConcurrentButTwiceSynchronizedHashMap” .. ;-)

By: ckbe

ckbe — Wed, 28 Jul 2010 01:07:21 +0000

The difference is, that if you decide at one point to use a synchronized() on a ConcurrentHashMap, you must synchronize each and every access explicitly and loose the benefit of the ConcurrentHashMap (The concurrency).
Whereas if you use the simpler synchronizedMap() and just do a synchronized() block around for example the iteration loop (or the constructor call of the ArrayList) everything works fine.

By: Jeffrey Smith

Jeffrey Smith — Tue, 27 Jul 2010 23:51:41 +0000

By the way, your purported solution won't work, because toArray() is not atomic.

Changing:
collection.toArray(array);

to:
array = collection.toArray(array);

will not avoid an array indexing error within the toArray() method. The exposure
to a concurrent modification is still present.

The assignments:
collection.toArray(array);
lastIndex = size;

should at least be changed to:
array = collection.toArray(array);
lastIndex = array.length;

but there is still an exposure within toArray() while constructing the
copy.

The simple solution is not to use unsynchronized collections within a
multi-threaded context.

By: Jeffrey Smith

Jeffrey Smith — Tue, 27 Jul 2010 23:38:42 +0000

The Collections.toArray() methods must be internally synchronized, or else they
will suffer the same fate. I suggest you look at their 1.6 implementations to verify
there is no internal race condition. I believe there is a race condition in the
ArrayList.toArray() methods, because that class is specifically documented as
not thread-safe. The internal changes to "elementData" and "size" fields are
separated in time without synchronization, and therefore are not thread-safe.

If there is no way to freeze changes from all threads for the collection while a copy
is constructed, then using the Iterator is clearly a client design flaw. The Iterator
API is not intended for multi-threaded access. The Collections.toArray() methods
are not atomic, unless the implementation specifically states that it is atomic.

ConcurrentModificationException thrown by the Iterator is intended solely to detect client
design flaws and bugs during application development. The ArrayIndexOutOfBoundsException
clearly shows that the client application is incorrectly using an ArrayList in a multi-threaded
context.

By: Jevgeni Kabanov

Jevgeni Kabanov — Tue, 27 Jul 2010 21:58:54 +0000

What difference does it make? Yes, CHM uses multiple monitors to sync, but semantically the result is the same, if faster.