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

[Vitaly Davidovich]

On Tuesday, February 23, 2016, Doug Lea <dl at cs.oswego.edu> wrote:

> 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.

vs who else logically speaking? We all know there's a runtime underneath
Java, there's no point in explicitly calling that out here.  Again, how is
this different from Thread::yield or any of the other mentioned examples?
This is splitting hairs perhaps but there's no onXXX precedent to follow
and this just throws an oddly looking method name into the mix.

> "onSpinWait" is the only proposed name that no one has said they cannot
> live with. So, live with it :-)

Perhaps that's because the Runtime placement was a more glaring issue? :)
It's livable but I just don't see the point of the prefix (and yes, I read
the description of the intent in the original mail).

>
> -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.
>>>
>>>
>>
>
>

-- 
Sent from my phone