• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Concurrent Collections - Iterate and Change

 
Ranch Hand
Posts: 241
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is an exam-specific question. I wonder if we do have to know the specific behaviour of each concurrent collection when iterating and changing, e.g.


or

I have done a similar experiment for all concurrent Collections. They are all different. Sometimes they update the values being iterated on with every iteration, sometimes they don't. Sometimes, they do only for adding elements, sometimes only for removing. I have found that this behaviour is consistent within each specific collection for each specific action (at least they didn't vary for me), but there is no consistency across collections.

My question is: do we really have to know the ins and outs of each concurrent Collection class for the exam? Or is it enough to know that iterators are weakly consistent, meaning:

1. they may proceed concurrently with other operations
2. they will never throw ConcurrentModificationException
3. they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction.


source: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summary.html#Weakly

Many thanks in advance for your help
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

T Vergilio wrote:My question is: do we really have to know the ins and outs of each concurrent Collection class for the exam? Or is it enough to know that iterators are weakly consistent, meaning:
...
3. they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction.


I'm afraid I can't answer your question specifically because I'm not familiar with the exam requirements, but that last point is contradictory.

EITHER an Iterator traverses elements "as they existed upon construction", OR it "reflect[s] any modifications subsequent to construction". It can't do both.

And usually it does the latter.

Winston
 
T Vergilio
Ranch Hand
Posts: 241
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Winston,

I think it means it will traverse the elements as they were for the very first iteration. After that, there are no guarantees and each Collection seems to do its own thing. Sometimes, the elements being iterated on will change to reflect changes in the Collection, sometimes they won't.

I couldn't find any consistency across collections though, so I am hoping the exam is not going to require candidates to know the exact behaviour of each. That would require an awful lot of memorisation!
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

T Vergilio wrote:I think it means it will traverse the elements as they were for the very first iteration.


And I suspect it's highly likely to depend on the type of structure.

My understanding of "weakly consistent" is that it usually means that next() returns the element mandated by the state of the structure at the time it was called, but it's also certainly possible for an Iterator to work on a "snapshot" of the collection taken at the time the Iterator was created.

This however, takes time, and concurrent structures are generally designed for "high throughput" (or minimum latency) in multi-threaded situations; so it wouldn't be my first choice if I was designing one.

On the other hand, an Iterator to a "linked" structure might well have to pre-fetch its "next" element when hasNext() is called in order to conform to the "weakly consistent" spec.

So: quite a few possibilities; and I doubt whether any single one is "right".

Winston
 
reply
    Bookmark Topic Watch Topic
  • New Topic