[concurrency-interest] Race conditions in concurrent collections

Doug Lea dl at cs.oswego.edu
Sun Sep 25 09:48:26 EDT 2005

Mike Skells wrote:
> For example isnt there a similar problem with hashCode(),or even toString(),
> or some other API that is being used that indirectly iterates, or calls
> equals ...

Right. The slogan is to use java.util.concurrent implementations for
all concurrently accessible collections. They are designed to handle
these operations in reasonable ways even under concurrent modification.
(Too bad that in Tiger we were still missing a few common ones
like ConcurrentSkipList{Map,Set} to substitute for Tree{Map, Set}.)
On the other hand, even though "reasonably" implemented,
some of these operations make little sense and should usually
be avoided when the collections are concurrently accessible.

For example, computing a hashCode for a collection that is undergoing
concurrent modification is almost never a good idea from an application
level point of view, so the fact that it doesn't throw an exception is
not all that helpful. It would almost be better for it to throw an
exception anyway to warn you that you are probably doing something
nonsensical, although that would be overly paternalistic :-)


More information about the Concurrency-interest mailing list