ConcurrentHashMap/ConcurrentMap/Map.compute (original) (raw)

Doug Lea dl at cs.oswego.edu
Fri Dec 14 11:54:04 PST 2012

On 12/14/12 13:32, Brian Goetz wrote:

There's always

map.entrySet().parallel().forEach()

I'm guessing you also declared the Map version in because it can take BiBlocks, not Block<Map.Entry>?

But if so, there's no way to get the par/seq distinction. Which might be OK because ...

But, let's uplevel this.

I'm not sure we want to, because we then hit some familiar territory that might be best avoided for JDK8:

- What other operations do you want to expose in parallel other than forEach?

Well, there are the ones exported in CHM. See pre-JDK8 snapshot still at: http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ConcurrentHashMap.html

These make for a nice minimal set for a null-intolerant unordered concurrently-weakly-iterable concurrent map. (Which is by far the most commonly encountered form for parallel bulk map ops. As in hadoop etc etc).

But generalizing these to apply to all possible maps leads to a lot of snags. Many more than collections/streams. (As you apparently agreed when scrapping MapStream.)

I had been thinking that the best move for JDK8 is for CHM itself to either only support parallel forms (as it does at the moment) or to offer both seq and par forms of these (foreach, mapped-foreach, search, reduce, mapped-reduce, and primitive-mapped-reduce, crossed by the four flavors: keys, values, entries, and Bi-forms), without trying to create new interfaces.

This move would give people a chance to take interface/framework issues up again someday.

But a near-term victim is that if you want to just add a common plain forEach(BiBlock), we have no good story about how to spec it to allow both seq and par forms, or a place to put it that would implicitly allow both forms.

Maybe just scrap it?

-Doug

More information about the lambda-libs-spec-experts mailing list