Re: The code example in onSpinWait() Javadoc

As Andrew pointed out in another comment, that'd be yield. So Fibers just
change the cost of yield, not a net new decision. (Although maybe you'll
get to choose between two yields)

Alex

On Mon, 18 Nov 2019, 16:03 Nathan and Ila Reynolds via
Concurrency-interest, <[email protected]> wrote:

> Another difficulty will be introduced with Project Loom and fibers.
> Will it be faster or better to switch to another fiber or spin?  This is
> highly dependent on the use case.
>
> -Nathan
>
> On 11/18/2019 8:48 AM, Gil Tene via Concurrency-interest wrote:
> >
> > Sent from my iPad
> >
> >> On Nov 18, 2019, at 5:30 AM, David Lloyd via Concurrency-interest <
> [email protected]> wrote:
> >>
> >> On Mon, Nov 18, 2019 at 4:37 AM Andrew Haley via Concurrency-interest
> >> <[email protected]> wrote:
> >>>> On 11/17/19 11:46 PM, Doug Lea via Concurrency-interest wrote:
> >>>>
> >>>> Usage may interact with GC, reference handling, and safepoints: in
> >>>> some contexts "a short while" isn't usually short, but we don't have
> >>>> a way of portably discussing such issues in javadocs. It's also one
> >>>> of the reasons we don't include a spinlock utility -- we cannot
> >>>> easily guess how best to write one that works well across enough
> >>>> usage contexts. (But we do make it easy to write them via tryLock.)
> >>> Sure, these ideas are hard to express if we restrict ourselves to
> >>> the mythical "write once, run anywhere" Java, but by the time we're
> >>> talking about writing our own spinlocks we're a long way from that.
> >>>
> >>> "Everybody" ;-) knows that you should only spin for about (half?) the
> >>> same time as a simple system call, and that this is about 1000
> >>> iterations of a trivial loop. Intuitively this makes sense: you don't
> >>> want to make an (expensive) system call rather than just waiting for a
> >>> little while.
> >> Should we not express this sentiment in the documentation somehow even
> >> if it is not perfectly applicable to every operating environment,
> >> since it's clearly not widely understood?
> > The sentiment is “common wisdom” for spinning ahead of a system call
> > that may be avoided by the spin succeeding (e.g. when waiting for a
> > condition variable that might soon be released). But it is far from
> universal
> > for spinning. And more importantly, should not be confused with “spinning
> > in user mode is common wisdom”.
> >
> > For one, when spinning for net work reduction, the thing you are hoping
> to
> > be able to avoid by spinning for may not involve a system call, but
> something
> > else that is much more expensive (like creating some additional resource,
> > resizing and rehashing a data structure, or zeroing megabytes of memory),
> > so the “how long is it worth spinning for?” math is closely dependent on
> > why you are spinning.
> >
> > But even more generally, spinning is used for much more than net work
> > reduction. It is (quite) often used for optimizing behavior in
> conjunction
> > with specific knowledge about e.g.  “what is more important”, “what is
> the
> > real bottleneck”, and “what thread can afford to spin forever if needed”
> > (e.g. because it is running on a dedicated isolcpu’ed vcore).
> >
> > Spinning in user mode is *always* running with scissors. Blindfolded.
> > There is no form of user mode spinning that I know of that is generally
> > “good advise” or should be “common practice”. They are all quite
> > dangerous. And IMO The short backoff ones are actually much more
> > dangerous (as in can cause tremendous harm when not coded by
> > experts, and can be very fragile under load) than the ones that just
> > spin forever. The ones that spin forever have much more apparent
> > behavior that is easy to detect  in testing and say “well, that was was
> > a silly thing to do” about. The ones that spin “only a little bit” can
> seem
> > to be a good thing for quite a while, and through much testing in nice
> > stable lab environments, especially to people who don’t already have
> > scars from falling down the massive cliffs that exist when slightly
> > prolonged resource holding starts making user-mode spinners start
> > delaying the threads holding the thing they spin for from releasing It.
> >
> > Kernels prevent context switches when holding a spin lock for a reason.
> >
> >> --
> >> - DML
> >>
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> [email protected]
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > _______________________________________________
> > Concurrency-interest mailing list
> > [email protected]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest