[concurrency-interest] Spin Loop Hint support: Draft JEP proposal
vitalyd at gmail.com
Tue Feb 23 21:30:45 UTC 2016
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 <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:
> >> and here:
> >> 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  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:
> 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.
More information about the core-libs-dev