mono-thread concurrent modification

Discussion in 'Java' started by jpprost@gmail.com, Nov 29, 2005.

  1. Guest

    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/>
    _______________________________________________
    , Nov 29, 2005
    #1
    1. Advertising

  2. Roedy Green Guest

    On 28 Nov 2005 22:12:03 -0800, wrote, quoted or
    indirectly quoted someone who said :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 29, 2005
    #2
    1. Advertising

  3. Roedy Green Guest

    On Tue, 29 Nov 2005 06:24:09 GMT, Roedy Green
    <> wrote, quoted or
    indirectly quoted someone who said :

    >
    >look at the methods of Iterator.


    sorry ListIterator.add. It inserts at the spot you are working on.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 29, 2005
    #3
  4. <> wrote in message
    news:...
    > 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.
    Mike Schilling, Nov 29, 2005
    #4
  5. Guest

    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/>
    _______________________________________________
    , Nov 29, 2005
    #5
  6. LaieTechie Guest

    On Tue, 29 Nov 2005 06:28:36 +0000, Mike Schilling wrote:

    > 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, Nov 29, 2005
    #6
  7. LaieTechie Guest

    On Tue, 29 Nov 2005 06:28:36 +0000, Mike Schilling wrote:

    > 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, Nov 29, 2005
    #7
  8. zero Guest

    wrote in news:1133246093.516969.140790
    @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.


    --
    Beware the False Authority Syndrome
    zero, Nov 29, 2005
    #8
  9. Chris Uppal Guest

    Mike Schilling wrote:

    > 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
    Chris Uppal, Nov 29, 2005
    #9
  10. "Chris Uppal" <-THIS.org> wrote in message
    news:438c39d0$1$20532$...
    > Mike Schilling wrote:
    >
    >> 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 !


    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, Nov 29, 2005
    #10
  11. <> wrote in message
    news:...
    > 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.
    Mike Schilling, Nov 29, 2005
    #11
  12. Chris Uppal Guest

    Mike Schilling wrote:

    > 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
    Chris Uppal, Nov 29, 2005
    #12
  13. Mike Schilling wrote:
    >
    > 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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Nov 29, 2005
    #13
  14. "Chris Uppal" <-THIS.org> wrote in message
    news:438c6e6b$0$20532$...
    > Mike Schilling wrote:
    >
    >> 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.


    Isn't *called* LikedCollection, I meant to type. (By implication,
    implements Collection but not List.)
    Mike Schilling, Nov 29, 2005
    #14
  15. "Thomas Hawtin" <> wrote in message
    news:438c83ef$0$1472$...
    > Mike Schilling wrote:
    >>
    >> 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.


    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?
    Mike Schilling, Nov 29, 2005
    #15
  16. Mike Schilling wrote:
    > "Thomas Hawtin" <> wrote in message
    > news:438c83ef$0$1472$...
    >>
    >>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);
    > ...
    > }
    > }


    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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Nov 29, 2005
    #16
  17. Guest

    [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/>
    _______________________________________________
    , Nov 29, 2005
    #17
  18. "Thomas Hawtin" <> wrote in message
    news:438cb3a0$0$1464$...
    > Mike Schilling wrote:
    >> "Thomas Hawtin" <> wrote in message
    >> news:438c83ef$0$1472$...
    >>>
    >>>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);
    >> ...
    >> }
    >> }

    >
    > 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.


    Based on what?
    Mike Schilling, Nov 30, 2005
    #18
  19. "Thomas Hawtin" <> wrote in message
    news:438cb3a0$0$1464$...
    >>
    >> 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,


    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.
    Mike Schilling, Nov 30, 2005
    #19
  20. Mike Schilling wrote:
    >>
    >>That's not "wrong". It might give you poor performance in unusual cases,

    >
    >
    > Is LinkedList an unusual case?


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

    >>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.


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

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Nov 30, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Manat K.

    Mono

    Manat K., Aug 9, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    791
    Natty Gur
    Aug 11, 2003
  2. Replies:
    1
    Views:
    2,736
    Scott Allen
    May 30, 2005
  3. Mono and SmartNavigation

    , May 30, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    360
  4. Coding Maniac

    ASP.NET and mono

    Coding Maniac, Jun 9, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    481
    Eliyahu Goldin
    Jun 9, 2005
  5. Pep
    Replies:
    6
    Views:
    811
Loading...

Share This Page