[concurrency-interest] ThreadPoolExecutor workQueue concurrency issue

Endre Stølsvik online at stolsvik.com
Wed Dec 12 03:43:50 EST 2007

Doug Lea wrote:
> Guy Korland wrote:
>> BTW, one small question can you explain the reason behind the 
>> PaddeAtomicReference?
> The Exchanger internal documentation has a better description
> of rationale -- see
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/Exchanger.java?view=log)

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?

I thought that one was supposed be able to dynamically scale this number 
- allocate a different set of processors to different processes over 
time (e.g. when you "stick" a processor onto two of four processors). 
Checking the JavaDoc, it indeed states:
   "This value may change during a particular invocation of the virtual 
machine. Applications that are sensitive to the number of available 
processors should therefore occasionally poll this property and adjust 
their resource usage appropriately."

I guess a response will be that it won't matter much - but nevertheless, 
this might end up being one of those gotchas when you have 64 
processors, start a process, and then scale it back heavily to only run 
on 2 processors. Or the other case - you start out with very few 
processors, and then scale it way up because of demand..

The static final-ness of the field (and further its internal static 
scaling of structures) means that even though you create it again if the 
available processors change, the new instance won't honor the new number.

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.


More information about the Concurrency-interest mailing list