miri: Miri hangs in spin loops forever

The following program loops forever in Miri, but terminates as expected with normal rustc:

use std::thread;
use std::sync::atomic::{AtomicUsize, Ordering};

static FLAG: AtomicUsize = AtomicUsize::new(0);

fn main() {
    let j = thread::spawn(|| {
        while FLAG.load(Ordering::Acquire) == 0 {
            // spin and wait
        }
    });
    thread::yield_now();
    FLAG.store(1, Ordering::Release);
    j.join().unwrap();
}

One could argue the spin loop should use hint::spin_loop();, but that is unstable – and it seems reasonable to expect the scheduler to de-schedule a thread at some point even if it does not yield.

Cc @vakaras

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (15 by maintainers)

Commits related to this issue

Auto merge of #1898 - Kixunil:patch-1, r=RalfJung Document threading support a bit more This adds a few known limitations around threading to the README and suggests the users to look into GitHub is... — committed to rust-lang/miri by bors 3 years ago
Merge #831 #832 831: Add spin loop hints in tests for Miri r=taiki-e a=cbeuw This is a better way to do #829 Miri does not have a pre-emptive scheduler, so once the execution falls into a spin l... — committed to crossbeam-rs/crossbeam by bors[bot] 2 years ago
Auto merge of #2197 - RalfJung:round-robin, r=RalfJung make Miri's scheduler proper round-robin When thread N blocks or yields, we activate thread N+1 next, rather than always activating thread 0. T... — committed to rust-lang/miri by bors 2 years ago
Auto merge of #2208 - RalfJung:preempt, r=RalfJung Make scheduler preemptive This is actually fairly easy. :D I just roll the dice on each terminator to decide whether we want to yield the active th... — committed to rust-lang/miri by bors 2 years ago

Most upvoted comments

Ah turns out there is a stable version of the same intrinsic, std::sync::atomic::spin_loop_hint().

We could do round robin, where every terminator causes the next thread to get activated.

I was more thinking “switch every N terminators”, but N = 1 is certainly a possible choice. 😉 We might make this configurable even.

RalfJung on May 3, 2020

It seems to me that a spinloop without spin_loop_hint() is undesirable so warning about that could be nice?

Hm, that might be the case (not sure if everyone would agree) but I don’t think Miri is necessarily the tool for detecting such things. None of the solutions I know of that would make Miri better at running such code would provide any avenue towards having such a warning.

RalfJung on Oct 11, 2021