ConcurrentHashMap/ConcurrentMap/Map.compute (original) (raw)
Brian Goetz brian.goetz at oracle.com
Fri Dec 14 10:32:00 PST 2012
- Previous message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Next message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
We do not have explicit parallel versions of forEach for anything yet. Existing forEach methods are inherently sequential.
But does any spec promise this? If you want parallel forEach you can do: coll.parallel().forEach() But what's up with Maps?
There's always
map.entrySet().parallel().forEach()
if this is the only case we're really worried about.
But, let's uplevel this.
- What other operations do you want to expose in parallel other than forEach?
- If you wanted to make the default of forEach parallel, how would the user ask for serial? What about other operations?
The issue of "parallel collections" is one that we deliberately sidestepped as a simplifying scope-reduction choice. Everything else we're doing here is either a simple serial extension to existing collection semantics (e.g., Collection.removeAll) or explicitly part of the Stream framework. So, we don't have an answer; my preference would be to not invent one a month before feature-freeze if we don't have to.
- Previous message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Next message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-experts mailing list