[concurrency-interest] Race conditions in concurrent collections

Doug Lea dl at cs.oswego.edu
Sat Sep 24 15:18:23 EDT 2005

Martin Buchholz wrote:
> One possible strategy for implementing Set.equals would be
> new HashSet(this).equals(new HashSet(other));
> which at one stroke eliminates concurrency issues 

Although this places the burden on the HashSet(Collection c)
constructor, which is not specified to do anything special
in the face of concurrent modifications of "c" (and in fact
is likely to fail).

More generally, the java.util Collection APIs are not especially
consistent about the behavior of "binary bulk" collection
methods (Collection-constructors, putAll, equals, etc.)
The java.util.concurrent ones (ConcurrentMap, BlockingQueue)
are pretty clear about most of these. But I'm not sure whether or how
more can be said about the others. For example, while most people would
rather obtain a possibly (and defensibly) inaccurate result than
deadlock for a call to equals  with two concurrently accessible
collections, the specs cannot mandate this because many other people
have implemented these interfaces over the years, so at best, any
guarantees would hold only for those classes in the JDK.

The JSR166 expert group should/will explore alternatives
on this though.


More information about the Concurrency-interest mailing list