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

Dávid Karnok akarnokd at gmail.com
Thu Feb 2 09:36:03 EST 2017


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 <aph at redhat.com>:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170202/466e2bd5/attachment.html>


More information about the Concurrency-interest mailing list