[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.

-- 
- DML


More information about the Concurrency-interest mailing list