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