> Do I have to
> sync to avoid this issue?
I don't think so. But try anyway and post the result.
Your code may have bugs....
> I'm getting a java.util.NoSuchElementException at high loads using
> java.util.concurrent.CopyOnWriteArraySet. I have one guess why and
[quoted text clipped - 34 lines]
> }
> }
If enqueue can be called in multiple threads, then there is a risk of
NoSuchElementException. For example:
Suppose thread A calls enqueue, and enqueue assigns to i the Iterator
reference iterator() returned, and i.hasNext() returns true. Now A gets
interrupted, thread B starts running, and thread B calls enqueue.
Thread B assigns to i the Iterator reference that its iterator() call
returned. At that point, the thread A Iterator becomes unreachable.
Thread B completes its enqueue call, leaving i referencing an iterator
that returned false from i.hasNext().
Now thread A gets control back, but i references the Iterator that
thread B was using. The thread A next call fails.
If the uses of the shared Iterator are finely interleaved, as they could
be on a dual processor, you could get other problems such as not passing
a particular message to some listeners.
However, it is a problem you created, by choosing to make i an instance
field forcing multiple threads to share the iterator reference. Why is
that necessary?
If i were local, each enqueue activation would be able to remember its
own Iterator reference.
Patricia
Daisy - 29 Oct 2006 13:04 GMT
Thank you Patricia for the excellent response.
I originally had i as a local variable, but moved it to be an instance
variable to make the code faster. I'll move it back being a local
variable.
Thanks
> > I'm getting a java.util.NoSuchElementException at high loads using
> > java.util.concurrent.CopyOnWriteArraySet. I have one guess why and
[quoted text clipped - 62 lines]
>
> Patricia