loop { thread::yield_now(); } causes 100% CPU usage

[pzmarzly]

I may be wrong, but I thought thread::yield_now() should work like thread::sleep_ms(1) (yes, I known there's preferred Duration struct). This may be caused by Linux kernel and not Rust's fault, but it leads to 100% CPU usage and PC heating up.

I tried this code:

use std::thread;
fn main() {
    for _ in 1..4 {
        thread::spawn(||  loop { thread::yield_now(); });
    }
    loop { thread::yield_now(); }
}

And ended up with 100% usage on 4-core CPU.

Meanwhile replacing thread::yield_now with thread::sleep_ms(1) drops usage to 0%. Also, following code using sync::mpsc (that according to documentation of yield_now() uses yield_now()) also (thankfully) uses 0% of CPU time:

use std::thread;
use std::sync::mpsc::channel;
fn main() {
    for _ in 1..4 {
        thread::spawn(|| {
            let (tx, rx) = channel();
            tx.send(1).unwrap();
            loop { rx.recv().unwrap(); }
        });
    }
    let (tx, rx) = channel();
    tx.send(1).unwrap();
    loop { rx.recv().unwrap(); }
}

rustc --version --verbose:

rustc 1.24.0-nightly (f8af59d95 2017-12-13)
binary: rustc
commit-hash: f8af59d95225d122e38bb5dceb1027844d4ce170
commit-date: 2017-12-13
host: x86_64-unknown-linux-gnu
release: 1.24.0-nightly
LLVM version: 4.0

uname -a: Linux pawel-pc 4.12.14-1-MANJARO #1 SMP PREEMPT Wed Sep 20 10:51:00 UTC 2017 x86_64 GNU/Linux

sudo cpupower frequency-info:

analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 800 MHz - 3.20 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3.20 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: 1.40 GHz (asserted by call to hardware)
  boost state support:
    Supported: yes
    Active: yes

I tried both sudo cpupower frequency-set -g powersave and sudo cpupower frequency-set -g performance. I was running all te code with cargo run --release.

[leoyvens]

From the manpage of the corresponding syscall on Linux:

If the calling thread is the only thread in the highest priority list at that time, it will continue to run after a call to sched_yield().

Perhaps that is the case. Anyways this behaviour is 100% determined by the OS. That documentation about channels looks misleading, which is a relevant docs issue.

[sfackler]

This is a docs issue, not a perf issue.

[Manishearth]

@gsollazzo please don't use the A-rustdoc label for doc bugs (I've had to untag a few). That label is specifically for issues about the rustdoc tool, not about issues with the contents of the stdlib docs.

[gsollazzo]

@Manishearth Ok, thanks! Will do :)

[the8472]

Depending on your goals (latency, power consumption, progress opportunities for other threads) poll+busy-wait loops may require a mix of pause(x86)/yield(arm) instructions, yielding to the scheduler and sleeps. possibly with backoffs for the pause and sleep intervals.

yield_now() is just a low-level building block you would use in more sophisticated spin loops.

[DevQps]

@steveklabnik Since this is behavior is platform dependent, do we actually want to document it? As @the8472 mentioned yield_now is somewhat of a low-level primitive. I wonder if we should close this issue or not. What do you think about this?

[the8472]

Maybe the documentation needs to be updated. E.g. it says channels use yield to give up the thread, but that's not really true (at least skimming the implementation) yield is only used for backoff in some cases while thread::park is used to actually deschedule the thread.

Additionally it would be good to mention that it's only a hint to the scheduler. Or link to the underlying OS primitive as an implementation note so people can learn about OS-specific behavior.

[steveklabnik]

Yes, I think a clarification would be best, along the lines of what @the8472 is talking about.

[crlf0710]

Should there be a function that works just likethread::sleep_ms(1)? This code doesn't capture the intention well.

[the8472]

I don't think such a thing belongs in the standard library because naive polling often is an anti-pattern. It prevents CPUs from entering power-save states and offers poor latency and scalability properties.

And in the cases where other alternatives are not available it one usually uses a more sophisticated approach involving loops over noops, pause instructions, yields and sleeps with backoffs. Something like that might belong in a library since it needs to be tuned depending on platform and what one is waiting on.

[godmar]

This may be fixed by PR 86916.
See https://doc.rust-lang.org/beta/std/thread/fn.yield_now.html