[concurrency-interest] ThreadPoolExecutor workQueue concurrency issue

Doug Lea dl at cs.oswego.edu
Wed Dec 12 10:42:43 EST 2007

Endre Stølsvik wrote:
> 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, 
> though?

Probably not, but could you try this and let me know how it goes?

In other words, if I thought that it would lead to serious problems,
I would not have done it this way. But no one seems to
actually turn processors on and off during execution of
systems with highly contended sync code. At least no one does
it and tells me about it. So I don't really know.

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

A side note; There is some progress on this front. GC folks are
looking into support for a variant of "ephemerons" (google it)
that can be used to avoid uncollectable weak key-value chains.
If/when available (as a new form of java.lang.ref denoting
refs that don't contribute to the reachability of Weak refs),
then ThreadLocal, WeakHashMap, and planned follow-ons can be to
changed to use them; finally really solving this problem.

> As a philosophical question, and pretty much off on a tangent: How long 
> time do you think Java will live? 

Much too hard for me to answer. :-) But those of us who write them
do think about core library classes as never actually being finished.


More information about the Concurrency-interest mailing list