tokio: Runtime gets stuck
Version
current master branch (27e5b41067d01c0c9fac230c5addb58034201a63)
Platform
Windows 10
Description
The following program gets stuck in a release build. After some amount of time, no more printouts will happen. This indicates that a wakeup got lost. I played a bit around, and discovered the following:
- The biggest difference lies within the value of
NR_ITERATIONS- the smaller it is the faster it gets stuck. Maybe an issue with tasks joining “too early”? - If the
task::spawnis removed, everything looks fine - Caught the issue in the debugger, but it only tells me one thread is waiting on
thread::park, and others are waiting on IO completion ports - The amount of runtime threads does not seem to make a difference. I just adjusted it to 1 to have less noise in the debugger.
- It does not seem to happen with the
current_threadruntime
use tokio::sync::Mutex;
use tokio::sync::oneshot::channel;
use std::sync::Arc;
async fn do_iteration() {
// Changing this to a higher value will prevent it from getting stuck
const NR_ITERATIONS: usize = 5;
let m = Arc::new(Mutex::new(()));//IntrusiveMutex::new((), true));
let (sender, receiver) = channel();
let m = m.clone();
tokio::spawn(async move {
for _ in 0..NR_ITERATIONS {
let _ = m.lock().await;
}
sender.send(());
});
receiver.await;
}
fn main() {
const NR_ITERATIONS: usize = 10000;
const BLOCK_ON_PER_RT: usize = 3000;
for i in 0 .. NR_ITERATIONS {
{
println!("Starting runtime {}", i);
let mut builder = tokio::runtime::Builder::new();
builder.thread_pool().num_threads(1);
let mut rt = builder.build().unwrap();
for _ in 0 .. BLOCK_ON_PER_RT {
rt.block_on(async {
do_iteration().await;
});
}
println!("Stopping runtime");
}
println!("Stopped runtime");
}
}
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (15 by maintainers)
Commits related to this issue
- runtime: fix lost wakeup bug in scheduler When checking if a worker needs to be unparked, the SeqCst load does not provide the necessary synchronization to ensure the scheduled task is visible to the... — committed to tokio-rs/tokio by carllerche 5 years ago
- runtime: fix lost wakeup bug in scheduler (#1788) When checking if a worker needs to be unparked, the SeqCst load does not provide the necessary synchronization to ensure the scheduled task is visi... — committed to tokio-rs/tokio by carllerche 5 years ago
With the
let state = State(self.state.fetch_add(0, SeqCst));change from #1788 I can not observe the issue anymore in any of the tests that I had been trying so far.