[concurrency-interest] The code example in onSpinWait() Javadoc

Alex Otenko oleksandr.otenko at gmail.com
Mon Nov 18 14:12:11 EST 2019

Exactly. How do you optimize the cost of spinning, if you don't have a cost


On Mon, 18 Nov 2019, 15:50 Gil Tene via Concurrency-interest, <
concurrency-interest at cs.oswego.edu> wrote:

> Sent from my iPad
> > On Nov 18, 2019, at 5:30 AM, David Lloyd via Concurrency-interest <
> concurrency-interest at cs.oswego.edu> wrote:
> >
> > On Mon, Nov 18, 2019 at 4:37 AM Andrew Haley via Concurrency-interest
> > <concurrency-interest at cs.oswego.edu> 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
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20191118/01c940bb/attachment.html>

More information about the Concurrency-interest mailing list