river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Space/outrigger suggestions (remote iterator vs. collection)
Date Wed, 19 Jan 2011 20:58:02 GMT
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 

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



View raw message