diff options
| author | Arno Haase <arno.haase@haase-consulting.com> | 2019-09-10 14:03:31 +0200 |
|---|---|---|
| committer | Arno Haase <arno.haase@haase-consulting.com> | 2019-09-10 14:03:31 +0200 |
| commit | 356b4c81a04d1db70621949b25c0cc80d5c94b8e (patch) | |
| tree | 8c4ff5d52cc31998300769b86ce8e5057b1981ed | |
| parent | 61dced18277a8cd55c963502db5a4cdf837858f3 (diff) | |
| download | rust-356b4c81a04d1db70621949b25c0cc80d5c94b8e.tar.gz rust-356b4c81a04d1db70621949b25c0cc80d5c94b8e.zip | |
documentation enhancement for 'spin loop hint': replace 'CPU' with 'CPU or core'
| -rw-r--r-- | src/libcore/hint.rs | 6 | ||||
| -rw-r--r-- | src/libcore/sync/atomic.rs | 6 |
2 files changed, 6 insertions, 6 deletions
diff --git a/src/libcore/hint.rs b/src/libcore/hint.rs index 6439fa0e0c8..9a581d90cc2 100644 --- a/src/libcore/hint.rs +++ b/src/libcore/hint.rs @@ -59,12 +59,12 @@ pub unsafe fn unreachable_unchecked() -> ! { /// busy-wait spin-loop without yielding control to the system's scheduler. /// /// Using a busy-wait spin-loop with `spin_loop` is ideally used in situations where a -/// contended lock is held by another thread executed on a different CPU and where the waiting +/// contended lock is held by another thread executed on a different CPU or core and where the waiting /// times are relatively small. Because entering busy-wait spin-loop does not trigger the system's /// scheduler, no overhead for switching threads occurs. However, if the thread holding the -/// contended lock is running on the same CPU, the spin-loop is likely to occupy an entire CPU slice +/// contended lock is running on the same CPU or core, the spin-loop is likely to occupy an entire CPU slice /// before switching to the thread that holds the lock. If the contending lock is held by a thread -/// on the same CPU or if the waiting times for acquiring the lock are longer, it is often better to +/// on the same CPU or thread or if the waiting times for acquiring the lock are longer, it is often better to /// use [`std::thread::yield_now`]. /// /// **Note**: On platforms that do not support receiving spin-loop hints this function does not diff --git a/src/libcore/sync/atomic.rs b/src/libcore/sync/atomic.rs index 8dfb19fa032..bdd045f7565 100644 --- a/src/libcore/sync/atomic.rs +++ b/src/libcore/sync/atomic.rs @@ -134,12 +134,12 @@ use crate::hint::spin_loop; /// busy-wait spin-loop without yielding control to the system's scheduler. /// /// Using a busy-wait spin-loop with `spin_loop_hint` is ideally used in situations where a -/// contended lock is held by another thread executed on a different CPU and where the waiting +/// contended lock is held by another thread executed on a different CPU or core and where the waiting /// times are relatively small. Because entering busy-wait spin-loop does not trigger the system's /// scheduler, no overhead for switching threads occurs. However, if the thread holding the -/// contended lock is running on the same CPU, the spin-loop is likely to occupy an entire CPU slice +/// contended lock is running on the same CPU or core, the spin-loop is likely to occupy an entire CPU slice /// before switching to the thread that holds the lock. If the contending lock is held by a thread -/// on the same CPU or if the waiting times for acquiring the lock are longer, it is often better to +/// on the same CPU or core or if the waiting times for acquiring the lock are longer, it is often better to /// use [`std::thread::yield_now`]. /// /// **Note**: On platforms that do not support receiving spin-loop hints this function does not |
