[concurrency-interest] Subject: Re: ConcurrentHashMapV8

Doug Lea dl at cs.oswego.edu
Sat Oct 8 08:02:18 EDT 2011


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.

At the time of JDK5/JSR166, it was more important to integrate
concurrent collections with plain java.util collections, so
we didn't pursue this. And even though signature-wise, you
could claim that Iterator extends ElementStream, the
null-means-exhausted rule makes them incompatible.

But with the advent of lambdas and bulk parallel operations,
it might be worth considering this as a way of supporting
stream-style processing in addition to forEach-style processing.
Which would amount to giving people two choices for how they'd
like to replace all their sequential iterator code. Or,
to allow gradual adoption at the expense of messiness,
supporting all three styles.

-Doug



More information about the Concurrency-interest mailing list