[concurrency-interest] ThreadPoolExecutor workQueue concurrency issue

Doug Lea dl at cs.oswego.edu
Wed Dec 12 07:02:42 EST 2007

Endre Stølsvik wrote:
> This might be a bit off-topic question, but isn't it unfortunate that 
> this class stores the number of CPUs in a static, final?

Maybe. But all uses of this in j.u.c code are the forms:
1. Providing overridable defaults (as in new ForkJoinPool()).
2. Providing initial internal sizing or spinning constants
that affect footprint and performance but not correctness
(as in Exchanger).

The current cases of second form mainly distinguish
uniprocessors vs multiprocessors. So if you have a lot
of processors on first use of, for example, an Exchanger,
and then shut all but one of them down, then you will get
worse performance that you'd get if you started with only
one. And vice versa. Changes from say 4 to 8 processors
have almost no effect on these tunings though.
This doesn't seem like an important enough practical
problem to warrant slowing down main functionality
in all cases in order to dynamically adapt.

> It just hit me when reading that first line of code - that this could 
> seem like one of those java internals that you will end up 
> special-handling in years to come.

You are right in general -- there are a few aspects
of some j.u.c. classes that are uncomfortably tied to typical
platform and usage characteristics; for example, using exactly
16 segments in ConcurrentHashMap. These will surely change
over time. I think it just comes with the territory.


More information about the Concurrency-interest mailing list