mono-thread concurrent modification

[jpprost]

Hi,

I can't find an implementation of Collection which would let me legally
add new elements to the very list I iterate on. Let me re-phrase: I
want to iterate on an array/list (or whatever structure which is
Collection-compatible) and in the meantime add new elements to this
list (say at the end), so that they are taken into account in the
iteration process. It's important to emphasize that I only need to add
new elements--no removal is required.
- A SynchronizedList doesn't help here, since my application is
mono-thread--and anyway even when faking a synchronized section I still
get a ConcurrentModificationException.
- I thought a ListIterator with a LinkedList would be the solution, but
no: I still get the same exception--though in theory I don't see the
problem: I should be allowed to add new elements at the end of a linked
list on which I iterate, shouldn't I?...

Do I really have to implement something myself, or should I have a
better look somewhere?

Cheers,

--
Jean-Philippe Prost [E6A 341, x9542]
Centre for Language Technology
Macquarie University ~ Sydney, Australia
<http://www.ics.mq.edu.au/~jpprost/>
_______________________________________________

 

[Roedy Green]

Let me re-phrase: I
want to iterate on an array/list (or whatever structure which is
Collection-compatible) and in the meantime add new elements to this
list (say at the end),

look at the methods of Iterator.

 

[Roedy Green]

look at the methods of Iterator.

sorry ListIterator.add. It inserts at the spot you are working on.

 

[Mike Schilling]

Hi,

I can't find an implementation of Collection which would let me legally
add new elements to the very list I iterate on. Let me re-phrase: I
want to iterate on an array/list (or whatever structure which is
Collection-compatible) and in the meantime add new elements to this
list (say at the end), so that they are taken into account in the
iteration process. It's important to emphasize that I only need to add
new elements--no removal is required.

If it's a list, why not just use an integer index to step through it; this
works fine when elements are added to the end. Just remember to compare it
to the current size() rather than the size() when the iteration started.

 

[jpprost]

Yes, that's what I thought but for some reason I still get the same
exception.

--
Jean-Philippe Prost [E6A 341, x9542]
Centre for Language Technology
Macquarie University ~ Sydney, Australia
<http://www.ics.mq.edu.au/~jpprost/>
_______________________________________________

 

[LaieTechie]

If it's a list, why not just use an integer index to step through it; this
works fine when elements are added to the end. Just remember to compare
it to the current size() rather than the size() when the iteration
started.

If it's a LinkedList, then by supplying an index, it has to walk from the
beginning - not very efficient.

Laie Techie

 

[LaieTechie]

If it's a list, why not just use an integer index to step through it; this
works fine when elements are added to the end. Just remember to compare
it to the current size() rather than the size() when the iteration
started.

If it's a LinkedList, then by supplying an index, it has to walk from the
beginning - not very efficient.

Laie Techie

 

[zero]

(e-mail address removed) wrote in @g49g2000cwa.googlegroups.com:

Yes, that's what I thought but for some reason I still get the same
exception.

What's the exact exception, and the code that produces it - would be
helpful if we could see the actual line that throws the exception, and some
code leading up to it.

 

[Chris Uppal]

If it's a list, why not just use an integer index to step through it; this
works fine when elements are added to the end. Just remember to compare
it to the current size() rather than the size() when the iteration
started.

And also remember to change the LinkedList (as in the OP's experiment) back to
an ArrayList !

-- chris

 

[Mike Schilling]

And also remember to change the LinkedList (as in the OP's experiment)
back to
an ArrayList !

Only if performance is an issue

To be honest, I'm not sure why a LinkedList isn't a LinkedCollection, since
performing random-access operations on one is a bad idea. (Or conversely,
why there isn't a RandomAcesssList interface that adds those methods, while
List merely adds the listIterator() method).

 

[Mike Schilling]

Yes, that's what I thought but for some reason I still get the same
exception.

You need to to the add using the iterator; any change to the List "behind
the iterator's back" causes the ConcurrentChangeException.

 

[Chris Uppal]

To be honest, I'm not sure why a LinkedList isn't a LinkedCollection,

By "LinkedCollection" do you mean "Collection" ? If so then I don't see a good
reason either.

-- chris

 

[Thomas Hawtin]

To be honest, I'm not sure why a LinkedList isn't a LinkedCollection, since
performing random-access operations on one is a bad idea. (Or conversely,
why there isn't a RandomAcesssList interface that adds those methods, while
List merely adds the listIterator() method).

Discriminating on the basis of immutability would come higher on my
list. It seems that the decision was made to have few interfaces for
collections, rather than have every possible combination.

Most uses of Lists are random access, so the names should go something
like List extends SeriallyAccessibleList. Even then an internal
implementation of get(int) would 'normally' be faster than an iterator
implementation, and also be easier to fit other optimisations to.

Tom Hawtin

 

[Mike Schilling]

By "LinkedCollection" do you mean "Collection" ? If so then I don't see a
good
reason either.

Isn't *called* LikedCollection, I meant to type. (By implication,
implements Collection but not List.)

 

[Mike Schilling]

Discriminating on the basis of immutability would come higher on my list.
It seems that the decision was made to have few interfaces for
collections, rather than have every possible combination.

Most uses of Lists are random access, so the names should go something
like List extends SeriallyAccessibleList. Even then an internal
implementation of get(int) would 'normally' be faster than an iterator
implementation, and also be easier to fit other optimisations to.

Suppose you're writing a method to process an arbitrary List. As things
are, it's very wrong to write:

void processList(List l)
{
for (int i = 0; i < l.size(); i++)
{
Object member = l.get(i);
...
}
}

since the performance could be horrific for a large LinkedList. It must be
written as

void processist(List l)
{
for (Iterator iter = l.iterator(); !iter.hasNext(); )
{
Object member = l.next();
...
}
}

Since the random access get() shouldn't be used on arbitrary lists, why is
it defined in the List interface?

 

[Thomas Hawtin]

Suppose you're writing a method to process an arbitrary List. As things
are, it's very wrong to write:

void processList(List l)
{
for (int i = 0; i < l.size(); i++)
{
Object member = l.get(i);
...
}
}

That's not "wrong". It might give you poor performance in unusual cases,
but so might many things. It would be more "wrong" to call add on a List
of unknown parentage, but we are happy to do that all the time.

since the performance could be horrific for a large LinkedList. It must be
written as

There is no must about it. Indeed java.util.Collections takes a smarter,
adaptive approach.

Tom Hawtin

 

[jpprost]

[catching up late, thanks to the time zones!]

You need to to the add using the iterator; any change to the List "behind
the iterator's back" causes the ConcurrentChangeException.

Yes, maybe I wasn't clear in my messages but that's exactly what I
meant: I did try the ListIterator, with the add() method that comes
with it (rather than the one from the Collection) and yet I still get
the ConcurrentModificationException.

As for the other suggestions:
- Yes, there's a big performance issue--as the module is involved in a
big combinatorial decision problem--, so indeed my first choice is to
go for an ArrayList. I just mentioned the LinkedList because I think
what I want should be possible at least with that kind of structure,
where the dynamic changes are a main motivation for it.

- I also agree that the good old "do-it-yourself" solution, with a
simple array and an integer index that I would manage myself is
probably what I'll end up adopting. I just thought there would be a
nice-and-neat implementation out there, which would embed everything in
a Collection-like kind of solution with iterator and everything, that
you can use as a black box. But now it looks like there is nothing
available, really. Never mind, I'll go for the "old fashion" way ;-)

--
Jean-Philippe Prost [E6A 341, x9542]
Centre for Language Technology
Macquarie University ~ Sydney, Australia
<http://www.ics.mq.edu.au/~jpprost/>
_______________________________________________

 

[Mike Schilling]

That's not "wrong". It might give you poor performance in unusual cases,
but so might many things. It would be more "wrong" to call add on a List
of unknown parentage, but we are happy to do that all the time.


There is no must about it. Indeed java.util.Collections takes a smarter,
adaptive approach.

Based on what?

 

[Mike Schilling]

That's not "wrong". It might give you poor performance in unusual cases,

Is LinkedList an unusual case?

but so might many things. It would be more "wrong" to call add on a List
of unknown parentage, but we are happy to do that all the time.

At least that throws an obvious exception, rather than silently being a
performance problem.

 

[Thomas Hawtin]

Is LinkedList an unusual case?

It should be. Else you've done it wrong.

At least that throws an obvious exception, rather than silently being a
performance problem.

I'd be much more happy going into production with something that wasn't
heavily optimised than something that stopped working.

Tom Hawtin