On 07/11/10 00:09, David Holmes wrote:
Doug Lea said the following on 07/10/10 23:35:
I've been trying out some improvements in ForkJoin
that involve repeatedly scanning threads to check
whether they are still in state Thread.State.RUNNABLE.
My question is why you want to check for Runnable? Is this a heuristic check to
see that the thread is not blocked? Only basic monitor related blocking will
update the thread state. Is that enough for what you want?
It's one part of a starvation detector for which it is OK
to be wrong conservatively.
For some of the motivation, see the concurrency-interest post
http://cs.oswego.edu/pipermail/concurrency-interest/2010-July/007251.html
That said the set of states is small enough that two arrays could easily be used
instead of the maps.
Or, depending on the range of values of Thread.threadStatus, bit
maps might work, and would avoid traversal.
Also, while I'm at it, field Thread.threadStatus is suspiciously not
declared volatile.
Or alternatively, is there a faster way to check that
internal field Thread.threadStatus has the value mapping
to RUNNABLE?
Can you use Unsafe to grab the field directly, or would the reflection make it
too slow?
That's what I'm currently doing as a sleazy workaround.
The sleaziness is not the Unsafe, which is basically fine
since this is planned for JDK code, but having to guess at startup
that the first value I get must be the one associated with RUNNABLE.
-Doug
