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

Gil Tene gil at azul.com
Mon Nov 18 10:48:41 EST 2019

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

More information about the Concurrency-interest mailing list