diff options
| author | Yuki Okushi <huyuumi.dev@gmail.com> | 2020-01-09 00:29:09 +0900 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-01-09 00:29:09 +0900 |
| commit | 256f401b85da7ae6e3d146a41089897c37c2589a (patch) | |
| tree | bb11420c7c9c655c1ab8b8f0aa6514e1f3af7d91 /src/test/debuginfo/enum-thinlto.rs | |
| parent | b85b1dd465e32dfdfe6a61d9ebffb1c5e50ac40b (diff) | |
| parent | b25eeef88d55a412c0e0bec7c0989d5a7969f195 (diff) | |
| download | rust-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
