[concurrency-interest] Spin Loop Hint support: Draft JEP proposal

[Doug Lea]

On 02/23/2016 04:30 PM, Vitaly Davidovich wrote:
> Why not drop the (superfluous, IMO) "on" prefix while you're changing the
> receiver?

Because then it reads as if the method itself is doing a spinWait.
"onSpinWait" is the only proposed name that no one has said they cannot
live with. So, live with it :-)

-Doug


>
> On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene <gil at azul.com> wrote:
>
>>
>>> On Feb 22, 2016, at 10:11 AM, mark.reinhold at oracle.com wrote:
>>>
>>> 2016/1/28 9:25 -0800, gil at azul.com:
>>>> This thread seems to have "hopped away" to the concurrency-interest
>>>> list in mid-Dec-2015. This posting is intended to capture a summary of
>>>> reasoning and some of the discussion there so that we have it in the
>>>> record in core-libs-dev. Mostly by including the contents of several
>>>> posts in the continuations of the original thread.
>>>>
>>>> See thread continuations here:
>>>>
>> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14576
>>>> and here:
>>>>
>> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14580
>>>>
>>>> Summary:
>>>>
>>>> ...
>>>
>>> Thanks for the summary.
>>>
>>> I still don't buy the argument that this method belongs in j.l.Runtime.
>>>
>>> To say that this method should go there because it's an instruction to
>>> the run-time system is pretty weak.  I agree with Vitaly [1] that if
>>> that's the threshold for adding methods to the Runtime class then lots
>>> of other stuff belongs there as well, including much of what's now in
>>> java.lang.Thread and java.util.concurrent and, arguably, anything else
>>> related to interacting with the environment in which the application
>>> runs (file and network I/O, process manipulation, etc.).
>>>
>>> This thread-related method really belongs in either java.lang.Thread or
>>> java.util.concurrent.LockSupport.  j.l.Thread already has plenty of
>>> expert-level static methods related to the current thread, one of which
>>> (Thread::yield) is even a hint, just like this one.  j.u.c.LockSupport
>>> is even more obviously intended for expert users and hence may be the
>>> best choice, but I could live with either one.
>>
>> Ok. In the interest of moving forward, lets settle on:
>>
>> Thread.onSpinWait()
>>
>> Same logic for the name, different receiver for the event. I can certainly
>> live with it, and Doug seems ok with it as well.
>>
>> — Gil.
>>
>