Patricia Shanahan wrote:
On 1/19/2011 12:58 PM, Peter Firmstone wrote:
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.
Note that there are multiple ways of achieving the specified semantics.
For example, ConcurrentLinkedQueue does not use a copy of the
collection. Instead, it depends on a combination of invariants,
including non-reuse of nodes, and volatile fields.
Sounds interesting, guess anythings possible, given enough thought.
Cheers,
Peter.
