Quantcast

JDK 9 FutureTask's use of Thread.yield

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JDK 9 FutureTask's use of Thread.yield

Dávid Karnok
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? 

--
Best regards,
David Karnok

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 FutureTask's use of Thread.yield

Andrew Haley
On 02/02/17 13:01, Dávid Karnok wrote:
> 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?

They aren't really equivalent.  onSpinWait() should be used on x86
systems whenever there is a spin, but it doesn't actually yield.  A
common pattern would be something like

   while (state == INTERRUPTING && counter-- > 0) {
       Thread.onSpinWait();
   }
   while (state == INTERRUPTING) {
       Thread.yield();
   }

which does a hard spin for a while, then backs off to using yield().

BTW, I'm not sure that Thread.onSpinWait() has an implementation other
than x86, where it generates a PAUSE instruction.

Andrew.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 FutureTask's use of Thread.yield

Dávid Karnok
Yes, I understand onSpinWait may be no-op on platforms and that Thread.yield() could be also no-op. 

But in case they actually do something, are there any implications for FutureTask in JDK 9 to have

 1) just the onSpinWait() loop, 
 2) both loops or 
 3) stay with the yield() loop? 

As a support argument, many similar spin loops have been changed to onSpinWait() in the JDK so I assume either this instance was overlooked or there is something else that depends on these kinds of loops in FutureTask to be yield().

2017-02-02 15:24 GMT+01:00 Andrew Haley <[hidden email]>:
On 02/02/17 13:01, Dávid Karnok wrote:
> 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?

They aren't really equivalent.  onSpinWait() should be used on x86
systems whenever there is a spin, but it doesn't actually yield.  A
common pattern would be something like

   while (state == INTERRUPTING && counter-- > 0) {
       Thread.onSpinWait();
   }
   while (state == INTERRUPTING) {
       Thread.yield();
   }

which does a hard spin for a while, then backs off to using yield().

BTW, I'm not sure that Thread.onSpinWait() has an implementation other
than x86, where it generates a PAUSE instruction.

Andrew.



--
Best regards,
David Karnok

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 FutureTask's use of Thread.yield

Doug Lea
In reply to this post by Dávid Karnok
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.


-Doug


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Loading...