[concurrency-interest] spinLoopHint() JEP draft discussion

Oleksandr Otenko oleksandr.otenko at oracle.com
Fri Oct 9 18:33:12 EDT 2015


Variable X transitions from value A to value B over time t.

What is the /expected/ reaction time of a spinning thread?

The answer is - it really depends on your cost model.

If you are waiting for X to become B, you may be waiting for up to t 
units of time. What difference would it make in your cost model, if 
instead it waited for N% of t more? When N% of t becomes larger than 
time to switch context, you yield. But this is a selfish model (my wait 
is more important than letting the others use the CPU).

Alex


On 07/10/2015 02:41, Gil Tene wrote:
> When comparing spinLoopHint() to Thread.yield(), we're talking about 
> different orders of magnitude, and different motivations.
>
> On the motivation side: A major reason for using spinLoopHint() is to 
> improve the reaction time of a spinning thread (from the time the 
> event it is spinning for actually occurs until it actually reacts to 
> it). Power savings is a another benefit. Thread.yield() doesn't help 
> with either.
>
> On the orders of magnitude side: Thread.yield involves making a system 
> call. This makes it literally 10x+ longer to react than spinning 
> without it, and certainly pulls in the opposite direction of 
> spinLoopHint().
>
>> On Oct 6, 2015, at 1:15 PM, Nathan Reynolds 
>> <nathan.reynolds at oracle.com <mailto:nathan.reynolds at oracle.com>> wrote:
>>
>> 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> 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> 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
>>
>>
>> _______________________________________________
>> 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/20151009/af4a5f99/attachment.html>


More information about the Concurrency-interest mailing list