[concurrency-interest] Race conditions in concurrent collections

Mike Skells mike.skells at ebizz-consulting.com
Sat Sep 24 20:33:28 EDT 2005


> -----Original Message-----
> From: Doug Lea [mailto:dl at cs.oswego.edu] 
> Sent: 25 September 2005 01:15
> To: Mike Skells
> Cc: concurrency-interest at altair.cs.oswego.edu
> Subject: Re: [concurrency-interest] Race conditions in 
> concurrent collections
> 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:
>    aConcurrentHashMap.equals(aHashtable)
>    aConcurrentHashMap.equals(aHashMap)
> 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.)
> -Doug

I was thinking not so much of the case when someone is dealing with a
collection per se, as when the ser is programming to say the object

Object x = ...
Object y = ...

If (x.equals(y)) {

I dont think that it is reasonable to write 

try {
   if (x.equals(y)) {
} catch RuntimeException re) {


Worse still not I come o think if it is the cases where you are indirectly
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 ...


More information about the Concurrency-interest mailing list