[concurrency-interest] ThreadPoolExecutor workQueue concurrency issue
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