Patricia Shanahan wrote:
Peter Firmstone wrote:
...
Yes I bumped into this recently when creating a concurrent policy
implementation, although it was with Enumeration, the backing set
cannot be modified while the Enumeration is being read from a loop,
the same with the iterator.
...
That depends on the implementation of the Iterator, and the Iterable's
related contract. There is nothing prohibiting concurrency-supporting
contracts. See, for example,
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html#iterator%28%29
Which is essentially the same way I've handled Iterators and a
concurrent underlying collection, by creating a copy of that collection,
it was current at the time of access, no Guarantees over time, the
copied collection is shared among all iterator readers, its reference is
nullified as soon as the underlying collection is written, then the next
iterator copy's the collection again. The currently executing
iterators, still hold a reference to the previous copy of the underlying
collection.
The foreach style loop is much nicer, the for loop example I provided
earlier isn't as intuitive.
I'm planning to make the FastList in outrigger Iterable, and follow
the ConcurrentLinkedQueue model. As the results looked in preliminary
benchmarking before I went on vacation, the best implementation is
based on ConcurrentLinkedQueue.
The issue of remoteness, and allowing remote-related exceptions, is
another issue. However, rather than giving up the nice loop syntax we
get with Iterable, we could consider wrapping in an unchecked exception.
I've pondered something like that too, it is important to remember that
the Iterator is still restricted to single thread access by the caller,
due to check then get, not being atomic.
The caller might have to be happy to live with duplicates in the
iterator, if it is updated during iteration, remembering every value
iterated could create memory problems. ;)
Cheers,
Peter.
