Why not drop the (superfluous, IMO) "on" prefix while you're changing the receiver? Thread::spinWait would be in the same style/spirit as Thread::yield, and I don't think there will be much contention.
On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene <g...@azul.com> wrote: > > > On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote: > > > > 2016/1/28 9:25 -0800, 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. >
