[concurrency-interest] spinLoopHint() JEP draft discussion

Nathan Reynolds nathan.reynolds at oracle.com
Tue Oct 6 16:15:36 EDT 2015


I am not fully up to speed on this topic.  However, why not call 
Thread.yield()?  If there are no other threads waiting to get on the 
processor, then Thread.yield() does nothing.  The current thread keeps 
executing.  If there are threads waiting to get on the processor, then 
current thread goes to the end of the run queue and another thread gets 
on the processor (i.e. a context switch).  The thread will run again 
after the other threads ahead of it either block, call yield() or use up 
their time slice.  The only time Thread.yield() will do anything is if 
*all* of the processors are busy (i.e. 100% CPU utilization for the 
machine).  You could run 1000s of threads in tight Thread.yield() loops 
and all of the threads will take a turn to go around the loop one time 
and then go to the end of the run queue.

I've tested this on Windows and Linux (Intel 64-bit processors).

Some people are very afraid of context switches.  They think that 
context switches are expensive.  This was true of very old Linux 
kernels.  Now a days, it costs 100s of nanoseconds to do a context 
switch.  Of course, the cache may need to be reloaded with the data 
relevant for the running thread.

-Nathan

On 10/6/2015 11:56 AM, Gil Tene wrote:
> A variant of synchronic for j.u.c would certainly be cool to have. 
> Especially if it supports a hint that makes it actually spin forever 
> rather than block (this may be what expect_urgent means, or maybe a 
> dedicated spin level is needed). An implementation could use 
> spinLoopHint() under the hood, or other things where appropriate (e.g. 
> if MWAIT was usefully available in user mode in some future, and had a 
> way to limit the wait time).
>
> However, an abstraction like synchronic is a bit higher level than 
> spinLoopHint(). One of the main drivers for spinLoopHint() is 
> direct-use cases by programs and libraries outside of the core JDK. 
> E.g. spinning indefinitely (or for limited periods) on dedicated 
> vcores is a common practice in high performance messaging and 
> communications stacks, as is not unreasonable on today's many-core 
> systems. E.g. seeing 4-8 threads "pinned" with spinning loops is 
> common place in trading applications, in kernel bypass network stacks, 
> and in low latency messaging. And the conditions for spins are often 
> more complicated than those expressible by synchronic (e.g. watching 
> multiple addresses in a mux'ed spin). I'm sure a higher level 
> abstraction for a spin wait can be enriched enough to come close, but 
> there are many current use cases that aren't covered by any currently 
> proposed abstraction.
>
> So, I like the idea of an abstraction that would allow uncomplicated 
> spin-wait use, but I also think that direct access to spinLoopHint() 
> is very much needed. They don't contradict each other.
>
> — Gil.
>
>> On Oct 6, 2015, at 9:49 AM, Hans Boehm <boehm at acm.org 
>> <mailto:boehm at acm.org>> wrote:
>>
>> If you haven't seen it, you may also be interested in
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0126r0.pdf
>>
>> which seems to be a very different perspective on roughly the same space.
>>
>> On Tue, Oct 6, 2015 at 8:11 AM, Gil Tene <gil at azulsystems.com 
>> <mailto:gil at azulsystems.com>> wrote:
>>
>>     I posted a draft JEP about adding spinLoopHint() for discussion
>>     on core-libs-dev and hotspot-dev. May be of interest to this
>>     group. The main focus is supporting outside-of-the-JDK spinning
>>     needs (for which there are multiple eager users), but it
>>     could/may be useful under the hood in j.u.c.
>>
>>     http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035613.html
>>
>>     See draft JEP, tests, and links to prototype JDKs to play with here:
>>     https://github.com/giltene/GilExamples/tree/master/SpinHintTest
>>
>>     — Gil.
>>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     Concurrency-interest at cs.oswego.edu
>>     <mailto:Concurrency-interest at cs.oswego.edu>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151006/f29f0ead/attachment-0001.html>


More information about the Concurrency-interest mailing list