onXXX is VERY relevant to this situation. And it's exactly that precedent and common convention for event notification calls that drove the choice of onSpinWait as a method name. onSpinWait() it is delivering a notification [from the calling code to the Runtime, or the Thread] about what is going on: a spin wait is in progress.
The fundamental difference between onSpinWait() and Thread.yield() is that yield() means "please yield here", while onSpinWait means "I am in the middle of busily executing a spin wait that I need no help with, and certainly don't want to be blocking in. But you might want to know about that and do something with that knowledge. Preferably something that improves my performance." Basically, onSpinWait() is delivering a notification of a situation, and the runtime has a chance to react to that. Dropping the "on" would completely change the meaning. Something called "spinWait" *is* like yield(). It would/should mean "please spin wait here". But that's not what spin wait constructs need or want in a call. Unlike yield(), spin wait constructs use their own logic for spinning, and usually need to retain control over the logic. They just need to let someone know that spinning is going on, in the hope that performance of the spinwait construct (with whatever logic it uses) might be improved. Note that the runtime reactions to being notified the calling code is in the middle of a spin wait could range from doing nothing, to doing something with instruction execution (e.g. execute an x86 pause instruction), to doing something more sophisticated (e.g. trying to dedicate a core to the spinning thread and steer all other thread and interrupts away from it to improve it's reaction time stats). What will actually happen is up to the runtime, and intentionally not specified. Per the JavaDoc, if the runtime does take action when it receives the onSpinWait() event, the action is intended "to improve the performance of invoking spin-wait loop constructions". You can hopefully/probably see why Runtime was a logical choice as the receiver of the event. Since Thread is also acceptable and defensible as the receiver of the event, I'm happy to go with it if it gets us over this name-can-of-worms thing. But please please please don't let us go into a whole method name redo again. We've done that on and off for 3+ months, and what we have is both logical and "not unacceptable": onSpinWait(). Let's just go with it. Thread.onSpinWait() FTW! > On Feb 23, 2016, at 8:03 PM, Vitaly Davidovich <vita...@gmail.com> wrote: > > Yes, I was going to mention onXXX being common for event handler names (e.g > onMouseClick), but didn't bother for the same reason you mentioned - it's > irrelevant to this situation. > > On Tuesday, February 23, 2016, Paul Benedict <pbened...@apache.org> wrote: > >> The onXXX prefix does have precedent as event handler callbacks, but this >> method does not fit that purpose. Thus, I agree dropping "on" is sensible. >> On Feb 23, 2016 8:48 PM, "Vitaly Davidovich" <vita...@gmail.com >> <javascript:_e(%7B%7D,'cvml','vita...@gmail.com');>> wrote: >> >>> On Tuesday, February 23, 2016, Doug Lea <d...@cs.oswego.edu >>> <javascript:_e(%7B%7D,'cvml','d...@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 <g...@azul.com >>> <javascript:_e(%7B%7D,'cvml','g...@azul.com');>> wrote: >>>>> >>>>> >>>>>> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com >>> <javascript:_e(%7B%7D,'cvml','mark.reinh...@oracle.com');> wrote: >>>>>>> >>>>>>> 2016/1/28 9:25 -0800, g...@azul.com >>> <javascript:_e(%7B%7D,'cvml','g...@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 >>> >> > > -- > Sent from my phone
