[Swift-devel] Coaster test failed at 86K of 100K jobs

Mihael Hategan hategan at mcs.anl.gov
Sat Aug 6 01:02:48 CDT 2011


Potential fix is in the 0.93 branch.

I'm not entirely sure that this was the problem, but it's the only one I
can see right now.

The issue is as follows. There is a "special" implementation of a
CopyOnWriteArrayList in the util module. The standard java one does a
copy of the underlying array for EVERY operation that changes the list.
This guarantees that ongoing iterations will not be messed up by
concurrent modifications to the list, but is very bad if you have many
operations that change the list.

The version in util only does a copy if there is an ongoing iteration on
a particular underlying array. If no concurrent changes and iterations
occur, this works at the speed of a normal synchronized list. If
concurrent changes and iterations occur, there is a copy penalty for
each iteration (but only once for each iteration).  This requires the
user code to notify the implementation when an iteration is done
(release).

The problem was with the way that the lock was implemented. It would be
increased for every iteration, set to 0 for each mutation operation and
decreased if > 0 for a release. That was broken, the following could
have occurred:

iteration1start  - lock = 1, with array1
add - lock > 0, copy to array2, lock = 0
iteration2start - lock = 1, with array2
iteration1end - lock = 0
add - lock == 0, add to array2 -> ConcurrentModificationException on
iteration2.

Though I don't see how the usage stats got to iterate twice at the same
time through stuff.

Mihael


On Fri, 2011-08-05 at 22:02 -0700, Mihael Hategan wrote:
> Amazing how that bug in what would otherwise be a relatively simple
> class (CopyOnWriteArrayList) has managed to survive so long. Concurrency
> ain't easy!
> 
> I'll have a fix committed after I do a bit of testing.





More information about the Swift-devel mailing list