Add more clarification to spin_loop docs - #159679
Conversation
rustbot
added
the
S-waiting-on-review
rustbot
added
the
T-libs
|
r? @aapoalas rustbot has assigned @aapoalas. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| /// | ||
| /// A common use case for `spin_loop` is implementing bounded optimistic | ||
| /// spinning in a CAS loop in synchronization primitives. To avoid problems | ||
| /// like priority inversion, it is strongly recommended that the spin loop is |
There was a problem hiding this comment.
The mention of priority inversion should not be lost. The main problem with spin locks that never yield to the scheduler isn't that they're less efficient, it's that they can completely explode when the thread that's in the critical section isn't running at all.
| /// [hardware threads]: https://en.wikipedia.org/wiki/Simultaneous_multithreading | ||
| /// | ||
| /// Because the operating system is not notified at all, this hint should be used only | ||
| /// when the expected wait time is short, i.e. a few instructions. Additionally, since |
There was a problem hiding this comment.
I think talking about "expected wait time" here is a red herring.
- If you're waiting on another thread, then there is generally no way to get a useful bound on how long it might take until that other thread releases the lock because that's up to the OS scheduler. Especially if you're spinning and thus potentially preventing the other thread from being scheduled. Critical section length in instructions or clock cycles has nothing to do with it.
- If you're doing a non-blocking CAS or LL/SC loop (like
Atomic*::updateis intended for), then the duration of the operation that the loop tried to does matter, but only because longer update sequences marginally increase the likelihood and cost of contention. In any case, such loops shouldn't usespin_loopin the first place (as the rest of this paragraph explains).
There was a problem hiding this comment.
Conversely: some mutex implementations (including std's futex-based one) happily do the optimistic N-iterations-of spinning even though they have no idea how long the critical sections protected by any particular mutex are. That's fine because it's a still a win when it works out, not too costly compared to the syscall when it doesn't work out, and the fallback to the syscall is still needed in any case.
rustbot
added
S-waiting-on-author
|
Reminder, once the PR becomes ready for a review, use |
4 participants
Follow-up to #159121.
Attempting to update the
spin_loopdocs to make it a little more clear what the use case for this hint is. Also uses the term "hardware thread" since "hyper-thread" is an Intel-specific term.