`SyncSender::send` enters a busy-wait loop if the buffer is full

[kawadakk]

Code

I tried this code:

fn main() {
    let (send, _recv) = std::sync::mpsc::sync_channel(1);
    send.send(());
    send.send(());
}

I expected to see this happen: Blocking indefinitely without consuming significant CPU time

Instead, this happened: 100% CPU usage (backtrace shown below)

#0  0x000055555556fc5a in core::iter::range::{impl#2}::spec_next<u32> (self=0x7fffffffd670)
    at /rustc/e631891f7ad40eac3ef58ec3c2b57ecd81e40615/library/core/src/iter/range.rs:621
#1  0x0000555555565320 in core::iter::range::{impl#3}::next<u32> ()
    at /rustc/e631891f7ad40eac3ef58ec3c2b57ecd81e40615/library/core/src/iter/range.rs:711
#2  std::sync::mpmc::utils::Backoff::spin (self=0x7fffffffd74c)
    at /rustc/e631891f7ad40eac3ef58ec3c2b57ecd81e40615/library/std/src/sync/mpmc/utils.rs:114
#3  0x0000555555568e79 in std::sync::mpmc::array::Channel<()>::send<()> (self=0x5555555bfc00, msg=(), deadline=...)
    at /rustc/e631891f7ad40eac3ef58ec3c2b57ecd81e40615/library/std/src/sync/mpmc/array.rs:333
#4  0x000055555556f1d7 in std::sync::mpmc::Sender<()>::send<()> (self=0x7fffffffd8f8, msg=())
    at /rustc/e631891f7ad40eac3ef58ec3c2b57ecd81e40615/library/std/src/sync/mpmc/mod.rs:127
#5  0x000055555556192e in std::sync::mpsc::SyncSender<()>::send<()> (self=0x7fffffffd8f8, t=())
    at /rustc/e631891f7ad40eac3ef58ec3c2b57ecd81e40615/library/std/src/sync/mpsc/mod.rs:687

rust/library/std/src/sync/mpmc/array.rs

Lines 322 to 335 in 51b0345

	// Try sending a message several times.
	let backoff = Backoff::new();
	loop {
	if self.start_send(token) {
	let res = unsafe { self.write(token, msg) };
	return res.map_err(SendTimeoutError::Disconnected);
	}
	if backoff.is_completed() {
	break;
	} else {
	backoff.spin();
	}
	}

Version it worked on

It most recently worked on: nightly-2022-11-13 (nightly), 1.66.0 (latest stable)

Version with regression

rustc --version --verbose:

rustc 1.67.0-nightly (e631891f7 2022-11-13)
binary: rustc
commit-hash: e631891f7ad40eac3ef58ec3c2b57ecd81e40615
commit-date: 2022-11-13
host: x86_64-unknown-linux-gnu
release: 1.67.0-nightly
LLVM version: 15.0.4

rustc 1.67.0-beta.6 (51b03459a 2022-12-31)
binary: rustc
commit-hash: 51b03459a49d03dbad7d120fb8575fc4580c057b
commit-date: 2022-12-31
host: x86_64-unknown-linux-gnu
release: 1.67.0-beta.6
LLVM version: 15.0.6

@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged

[Noratrieb]

cc @ibraheemdev

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium T-compiler

[ibraheemdev]

Are you seeing this issue in real world code?

[taiki-e]

The problem is that the loop uses Backoff::spin and Backoff::is_completed. Backoff::spin only increases step up to SPIN_LIMIT, so Backoff::is_completed that refers to YIELD_LIMIT never returns true.

rust/library/std/src/sync/mpmc/array.rs

Lines 330 to 334 in 51b0345

	if backoff.is_completed() {
	break;
	} else {
	backoff.spin();
	}

rust/library/std/src/sync/mpmc/utils.rs

Lines 118 to 120 in 51b0345

	if self.step.get() <= SPIN_LIMIT {
	self.step.set(self.step.get() + 1);
	}

rust/library/std/src/sync/mpmc/utils.rs

Lines 141 to 143 in 51b0345

	pub fn is_completed(&self) -> bool {
	self.step.get() > YIELD_LIMIT
	}

We need to use Backoff::snooze like crossbeam-channel does, or change Backoff::spin to increases step until YIELD_LIMIT.