1
Fork 0

rewrote documentation for thread::yield_now()

The old documentation suggested the use of yield_now for repeated
polling instead of discouraging it; it also made the false claim that
channels are implementing using yield_now. (They are not, except for
a corner case).
This commit is contained in:
Godmar Back 2021-07-06 15:50:42 -04:00
parent d04ec47358
commit fb464a3b39

View file

@ -651,22 +651,23 @@ pub fn current() -> Thread {
/// Cooperatively gives up a timeslice to the OS scheduler. /// Cooperatively gives up a timeslice to the OS scheduler.
/// ///
/// This is used when the programmer knows that the thread will have nothing /// This calls the underlying OS scheduler's yield primitive, signaling
/// to do for some time, and thus avoid wasting computing time. /// that the calling thread is willing to give up its remaining timeslice
/// so that the OS may schedule other threads on the CPU.
/// ///
/// For example when polling on a resource, it is common to check that it is /// A drawback of yielding in a loop is that if the OS does not have any
/// available, and if not to yield in order to avoid busy waiting. /// other ready threads to run on the current CPU, the thread will effectively
/// busy-wait, which wastes CPU time and energy.
/// ///
/// Thus the pattern of `yield`ing after a failed poll is rather common when /// Therefore, when waiting for events of interest, a programmer's first
/// implementing low-level shared resources or synchronization primitives. /// choice should be to use synchronization devices such as [`channel`]s,
/// [`Condvar`]s, [`Mutex`]es or [`join`] since these primitives are
/// implemented in a blocking manner, giving up the CPU until the event
/// of interest has occurred which avoids repeated yielding.
/// ///
/// However programmers will usually prefer to use [`channel`]s, [`Condvar`]s, /// `yield_now` should thus be used only rarely, mostly in situations where
/// [`Mutex`]es or [`join`] for their synchronization routines, as they avoid /// repeated polling is required because there is no other suitable way to
/// thinking about thread scheduling. /// learn when an event of interest has occurred.
///
/// Note that [`channel`]s for example are implemented using this primitive.
/// Indeed when you call `send` or `recv`, which are blocking, they will yield
/// if the channel is not available.
/// ///
/// # Examples /// # Examples
/// ///