[concurrency-interest] Race conditions in concurrent collections

Doug Lea dl at cs.oswego.edu
Sat Sep 24 20:15:06 EDT 2005

Mike Skells wrote:
> If you catch a ConcurrentModificationException  then equals() return false,
> because at some time during the evaluation the collection was not equal
> Similarly a NoSuchElementException should be caught and the collections
> should not be equal unless they are == (in which case we should not the
> iterating)
> Both ConcurrentModificationException and NoSuchElementException are not
> reasonable expected from a .equals() call. 

Issues like this are why concurrent collection iterators do not
throw these exceptions unexpectedly, so these problems should never
arise when dealing solely with concurrent collections. But I agree
that it would be nice if something better can be said and done
with calls using other kinds of collections, like:

I still don't know what that something is though. While it would
make sense to simply return false here if a Hashtable iterator
throws ConcurrentModificationException, it would not be
a good idea for a HashMap iterator, because in that case
the ConcurrentModificationException almost surely reflects
some kind of corruption -- it acts as a error that would be
swallowed if it simply triggers equals to return false.

(Note that concurrent/blocking queues evade these issues
entirely by relying on identity-based equality. Ideally,
most or all other concurrent collections would as well, but
doing so would have made it more difficult for people to switch from
java.util classes to instead use them.)


More information about the Concurrency-interest mailing list