[concurrency-interest] JDK 9 FutureTask's use of Thread.yield

Doug Lea dl at cs.oswego.edu
Thu Feb 2 15:39:16 EST 2017

On 02/02/2017 08:01 AM, Dávid Karnok wrote:
> I'm trying to port some some building blocks of Java's ExecutorServices
> to less fortunate platforms and I've noticed FutureTask of JDK 9 uses
> Thread.yield in some of its spin loops
> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/e170c858888e/src/java.base/share/classes/java/util/concurrent/FutureTask.java#l333
> for example) to wait some other party to finish up.
> Maybe this was discussed before, but wouldn't it make more sense to have
> Thread.onSpinWait() at these locations (now that it is available) just
> by itself or as a code that leads to the current Thread.yield() approach?

Every use of Thread.onSpinWait and/or Thread.yield and/or some sort of
(possibly timed) blocking synchronization requires a rough prediction
about the cause of the blockage. When there's a good chance that it
is in part due to underprovisioning (many runnable threads, few
available CPUs), we don't normally use spin-waits. In other words, we
use spins in those  cases where by nature of component usages, there is
likely to be available parallelism (for example in Phasers). Which can
be overly conservative, and subject to re-evaluation from time to time.
In partial compensation, in almost all cases, we support poll-style
vs blocking methods that allow users themselves to attach spin loops
when it makes sense.


More information about the Concurrency-interest mailing list