On May 29 2013, at 06:11 , Doug Lea wrote: > On 05/28/13 15:07, Mike Duigou wrote: >> Hi Chris & Doug; > >> - I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type >> particularly for newKeySet(). Why not return Set<K>? The additional methods >> don't seem to offer much that's desirable for the newKeySet() case. > > Since we don't have a ConcurrentSet interface, people are reduced to > instanceof checks to see if they have a concurrent one. But without > exposing the class, they couldn't even do this, so complained. This > will arise more frequently with j.u.streams.Collectors.
I'd rather introduce a vacuous ConcurrentSet than expose ConcurrentHashMap.KeySetView. Any reason not to add it? >> - I am reluctant to deprecate contains(Object) here unless we deprecate it in >> Hashtable as well. I recognize that this has been a source of errors >> (https://issues.apache.org/bugzilla/show_bug.cgi?id=48755 for one example). >> Is it time to deprecate it there as well? > > Sure, but why bother. Anyone still using Hashtable is not going to care > if they get more deprecation warnings :-) Fair enough. I will create a bug for deprecating Hashtable.contains as well but am fine with marking it deprecated here. >> - I think there could be more complete description of the >> parallelismThreshold and interaction with common pool. i.e. does "maximal >> parallelism" mean one thread per element or "size() / >> getCommonPoolParallelism()". Some advice for choosing in-between values would >> be good unless "1" is the best advice for cases where you just don't know. It >> would be a shame to see people shooting themselves in the foot with this. >> > > Changed to: > > * <p>These bulk operations accept a {@code parallelismThreshold} > * argument. Methods proceed sequentially if the current map size is > * estimated to be less than the given threshold. Using a value of > * {@code Long.MAX_VALUE} suppresses all parallelism. Using a value > * of {@code 1} results in maximal parallelism by partitioning into > * enough subtasks to utilize all processors. Normally, you would > * initially choose one of these extreme values, and then measure > * performance of using in-between values that trade off overhead > * versus throughput. Parallel forms use the {@link > * ForkJoinPool#commonPool()}. > * only one change I would make is : Using a value of {@code 1} results in maximal parallelism by partitioning into enough subtasks to fully utilize the {@link ForkJoinPool#commonPool()}. > > I'd rather not explicitly mention here any particular values for people > to try, since any number we might put is likely to be misused. Yes, that would almost certainly be misused. > Sometime, we should write up a little how-to document about > tuning parallelism separately. > > -Doug > >
