[concurrency-interest] ThreadPoolExecutor workQueue concurrency issue

Endre Stølsvik online at stolsvik.com
Wed Dec 12 08:28:25 EST 2007

Doug Lea wrote:

> 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.

I get the general point about not slowing the general case down due to 
fringe situations. However, letting this be decided at instantiation 
time instead of in a static final would at least make it possible for 
application code to adapt to changing situations by recreating the 
setup. The current code fully removes that possibility.

And 4 to 8 might not be a big problem, but 2 to 64, or 64 to 2 could be, 

>> 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.

As long as it is possible to change the constant 16 in CHM in future 
releases without breaking existing code, and existing understanding, I 
don't really see that particular example as problematic.

When I was talking about special-handling in years to come, I was 
thinking more of the user side: I've personally been bitten quite 
annoyingly (as in "wasted lots of time on completely unnecessary bug 
hunting and kludge-making") by ThreadLocals' that wont let go of users' 
ClassLoaders, DriverManager's retention of drivers, 
Introspector.flushCaches() and so on. Also, you have the discussion of 
the AWT EDT - how and when to construct GUI objects - for which 
recommendations (or requirements) have changed several times, and which 
have been a problem pretty much since Java was born.
   All things that just wasn't obvious in any way, gave lots of 
headaches (and maybe missed Java enthusiasts!), and that happened due to 
some small implementation detail years before.

My point is really that I can envision there will be threads in the 
future complaining about "Oh my god - why is that damn class fetching as 
a constant a number that in the javadoc is clearly stated as being 

4 processors will be normal on desktops within two years. Uniprocessor 
desktops will be far apart rather soon ("soon" are of course slightly 
relative here - but think 5 years). In some time, maybe 32 CPUs on a 
desktop system will be normal, and OSes might start controlling 
processes not only on nice levels, but on the number of CPUs they are 
allowed to run on..!

As a philosophical question, and pretty much off on a tangent: How long 
time do you think Java will live? Because if the answer is "a real good 
long time", then things should (obviously) strive to be rather perfect 
on the first time round, APIs being adjustable to future situations, and 
easy to learn and use - striving to making future API additions unnecessary.
   The j.u and of course in particular j.u.c are pretty intense already, 
learning curve wise, even usage wise to a degree. The same have 
obviously started to go for "Java itself" - witness the different 
frameworks popping up trying to be a shell over Java.
   Looking at Java these days, I can surely understand the argument 
about killing Java by making the recruitment criteria impossible: Java 
could end up being the best platform there is for many tasks, but it is 
just way to hard to learn.


More information about the Concurrency-interest mailing list