about summary refs log tree commit diff
path: root/src/test/debuginfo/enum-thinlto.rs
diff options
context:
space:
mode:
authorYuki Okushi <huyuumi.dev@gmail.com>2020-01-09 00:29:09 +0900
committerGitHub <noreply@github.com>2020-01-09 00:29:09 +0900
commit256f401b85da7ae6e3d146a41089897c37c2589a (patch)
treebb11420c7c9c655c1ab8b8f0aa6514e1f3af7d91 /src/test/debuginfo/enum-thinlto.rs
parentb85b1dd465e32dfdfe6a61d9ebffb1c5e50ac40b (diff)
parentb25eeef88d55a412c0e0bec7c0989d5a7969f195 (diff)
downloadrust-256f401b85da7ae6e3d146a41089897c37c2589a.tar.gz
rust-256f401b85da7ae6e3d146a41089897c37c2589a.zip
Rollup merge of #67798 - matklad:spin-thouse-docs, r=Amanieu
Remove wrong advice about spin locks from `spin_loop_hint` docs

Using a pure spin lock for a critical section in a preemptable thread
is always wrong, however short the critical section may be. The thread
might be preempted, which will cause all other threads to hammer
busily at the core for the whole quant. Moreover, if threads have
different priorities, this might lead to a priority inversion problem
and a deadlock. More generally, a spinlock is not more efficient than
a well-written mutex, which typically does several spin iterations at
the start anyway.

The advise about UP vs SMP is also irrelevant in the context of
preemptive threads.

See also accompanying piece: https://matklad.github.io/2020/01/02/spinlocs-considered-harmful.html

And another, independent piece: https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is

EDIT: obligatory disclosure that I am not an expert in these things, and might be terribly wrong :)
Diffstat (limited to 'src/test/debuginfo/enum-thinlto.rs')
0 files changed, 0 insertions, 0 deletions