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

Nathan and Ila Reynolds nathanila at gmail.com
Mon Nov 18 11:03:01 EST 2019

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.


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 <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

More information about the Concurrency-interest mailing list