[concurrency-interest] ConcurrentHashMapV8

Gregg Wonderly gregg at cytetech.com
Fri Oct 7 15:57:58 EDT 2011

On 10/7/2011 9:45 AM, Mark Thornton wrote:
> On 07/10/11 15:32, David M. Lloyd wrote:
>> Yeah, but I think that's not outside of what should be reasonably expected
>> when you iterate a (non-COW) concurrent hash map. As you say, hasNext()/next()
>> can be made consistent by actually getting a snapshot ref to the next entry in
>> hasNext(), but it doesn't have to be a copy of the Entry, it can still be the
>> literal Entry in the map.
> I have several nonconcurrent map implementations which do not have Entry
> instances internally --- they are created on the fly as needed to satisfy the
> entrySet requirements. I usually do this where I can't afford the space required
> by literal Entry instances.

It is important for an iterator to snapshot if you can ask it for the next 
entry.  What would be better, to avoid copying and to manage concurrency easier, 
without the hasNext()/next() issue, would be to have iteration functionality in 
an expression so that there was no hasNext()/next() pairing. But rather put the 
collection in control of performing a call out to the "task" for the next 
element in the collection.  As in something like

public interface IterationPoint<T> {
	public void iterateFor( T value );

public interface IterationProvider<T> {
	public int iterateOver( IterationPoint<T> point );

This would then allow complete freedom from hasNext()/next() pairing because 
only if the collection found another value, would it need to reveal it to the 

Lambdas would make this easy, but even with inner classes, it's still usable.

Gregg Wonderly

More information about the Concurrency-interest mailing list