[concurrency-interest] ThreadPoolExecutor workQueue concurrency issue
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
> The Exchanger internal documentation has a better description
> of rationale -- see
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