时间戳

首页 > 解决方案 > 为什么将 Tokio 与 std::sync::Mutex 一起使用时会出现死锁？

asynchronous - 为什么将 Tokio 与 std::sync::Mutex 一起使用时会出现死锁？

问题描述

我在使用 Tokio 时偶然发现了死锁情况：

use tokio::time::{delay_for, Duration};
use std::sync::Mutex;

#[tokio::main]
async fn main() {
    let mtx = Mutex::new(0);

    tokio::join!(work(&mtx), work(&mtx));

    println!("{}", *mtx.lock().unwrap());
}

async fn work(mtx: &Mutex<i32>) {
    println!("lock");
    {
        let mut v = mtx.lock().unwrap();
        println!("locked");
        // slow redis network request
        delay_for(Duration::from_millis(100)).await;
        *v += 1;
    }
    println!("unlock")
}

产生以下输出，然后永远挂起。

lock
locked
lock

根据Tokio docs，使用std::sync::Mutex是可以的：

与流行的看法相反，在异步代码中使用标准库中的普通 Mutex 是可以的，并且通常更喜欢。

但是，用Mutexa替换tokio::sync::Mutex不会触发死锁，并且一切都“按预期”工作，但仅限于上面列出的示例情况。在现实世界的场景中，延迟是由一些 Redis 请求引起的，它仍然会失败。

我认为这可能是因为我实际上根本没有产生线程，因此，即使“并行”执行，我也会锁定同一个线程，因为 await 只会产生执行。

在不产生单独线程的情况下实现我想要的 Rustacean 方法是什么？

标签： asynchronousrustmutexrust-tokio

解决方案

在这里使用 a不好的原因std::sync::Mutex是你把它放在了.await点上。在这种情况下：

  • 任务 1 持有互斥锁，但在delay_for.
  • 任务 2 被调度并运行，但无法获取 Mutex，因为它仍然由任务 1 拥有。它将在获取 Mutex 时同步阻塞。

由于任务 2 被阻塞，这也意味着运行时线程被完全阻塞。它实际上无法进入其计时器处理状态（当运行时空闲且不处理用户任务时发生），因此无法恢复任务 1。

因此，您现在正在观察死锁。

==> 如果您需要在一个.await点上保持互斥锁，则必须使用异步互斥锁。如 tokio 文档所述，同步互斥锁可以与异步程序一起使用 - 但它们可能不会跨.await点保存。

推荐阅读