[concurrency-interest] Subject: Re: ConcurrentHashMapV8

David M. Lloyd david.lloyd at redhat.com
Sat Oct 8 10:40:13 EDT 2011

On 10/08/2011 07:02 AM, Doug Lea wrote:
> On 10/08/11 06:26, Peter Firmstone wrote:
>> With Reference to Iterators, why not do something like this:
>> interface AtomicIterator<T> extends Iterator<T>{
>> T getIfHasNext();
>> }
> Back in pre-JSR166 days, I considered uniformly using
> a stream-like interface style along these lines for concurrent
> collections instead of Iterator, to avoid the hasNext/next
> non-atomicity problem in a classic way similar to IO and
> channel APIs. Recasting without the Iterator connection:
> interface ElementStream<T> {
> T next(); // return next element, or null if there aren't any
> }
> This works in part because nulls are generally disallowed
> in concurrent collections. (An ElementStream for an
> array-like collection like CopyOnWriteArrayList that
> can legitimately contain null gaps would need
> to internally skip over them when presenting next().)
> It also meshes nicely with the various Queue APIs -- Queue.poll
> is a "mutative" version of next() that also removes the element.

Of the two issues, I don't really find this one to be all that severe 
(it's easy enough to work around in most cases) - which is a good thing, 
since even if a superior alternative were implemented today, I imagine 
it would be many, many years before classical Iterators fell out of 
common usage.  In any case, it seems certain that lambdas will sand off 
this rough edge.


More information about the Concurrency-interest mailing list