Why is the std::sync::Mutex usually preferred over the tokio one?

[WhiteBlackGoose]

Hello everyone,

we had a chat on the discord server about mutexes, and apparently, the tokio's docs page on Mutex says this:

Contrary to popular belief, it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code

I'm not sure I understand why the former is a good idea. In particular, using the regular mutex, unlike the async one, blocks the runtime worker instead of just blocking the executing task. With async runtimes normally running on thread pools it might lead to a thread starvation and threads running idle awaiting the mutex.

Here's an easy to imagine scenario:

1. Create many tasks which access some shared data via the standard mutex
2. Alongside create other tasks which do something else
3. Now threads will be running the tasks in parallel until hitting that mutex, and from that point on, only one thread will be active, while all others will be idling
4. The invariance that there's only one concurrent access to a resource is still stands. However, because threads are idling but tasks haven't yielded, the user is just wasting real time beacuse other tasks arne't executed at all for no reason

With an async mutex all tasks hitting the mutex would yield and then rescheduled as the resource is freed, so worker threads will always be doing some useful work.

My feeling is: it's better to use something "safe", i. e. the async mutex, over something that is perhaps less expensive, and only go for the latter if an optimisation is needed (ofc in that case the critical section must be short, bound, and not contain await points).

Please correct me if I'm wrong.

[ADD-SP]

This is because the async locking is not free, for example, the async Mutex uses the sync Mutex internally to protect the waker list. So if the lock contention is not significant, the sync Mutex is usually faster.

[WhiteBlackGoose]

See my post. It's not less safe per Rust definition of safety, but going a bit further, the async one is safer because the normal mutex can cause a thread contention and the whole thread pool idling for no reason. The docs also don't mention this risk that I described above.

If a future get cancelled while holding a async mutex guard, it is hard to check correctness of the entire system.

Hmm, won't the cancelled future be dropped, releasing it?

[ADD-SP]

Hmm, won't the cancelled future be dropped, releasing it?

From tokio's perspective, it doesn't matter, but not for the application.

struct Data {
    num: tokio::sync::Mutex<Option<u8>>
}

impl Data {
    fn new() -> Self {
        Self { num: tokio::sync::Mutex::new(Some(0)) }
    }
}

async fn update(data: Arc<Data>) {
    let guard = data.num.lock().await;
    let old_num: u8 = guard.take().unwrap();
    let new_num = get_new_num(old_num).await;
    guard.replace(old_num);
}

For example, if the future get cancelled on let new_num = get_new_num(old_num).await;, the Option will be None. However, this case cannnot happen on std::sync::Mutex except we kill the OS thread.

[ADD-SP]

the async one is safer because the normal mutex can cause a thread contention and the whole thread pool idling for no reason.

For this "safer" concept, I agree, but this concept is confusing for me, it looks more close to performance area.

The docs also don't mention this risk that I described above.

In my opinion, this falls under the fundamentals of asynchronous programming. Of course, we could create dedicated documentation for this topic, but we simply cannot document every single foundational concept.

[ADD-SP]

Contrary to popular belief, it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code

I would say this is a rule of thumb. It typically performs faster and avoids system correctness issues that arise when cancellation occurs. Of course, applications can flexibly adjust this based on the specific scenario.

[WhiteBlackGoose]

For example, if the future get cancelled on let new_num = get_new_num(old_num).await;, the Option will be None. However, this case cannnot happen on std::sync::Mutex except we kill the OS thread.

But doesn't this collide with another concept, that is namely cancel safety? There are really endless scenarios when a cancel-unsafe task being cancelled leads to a disaster, and this one is rather innocent. Especially when it has to do with data integrity, e. g. you're writing to a file and reading from another via a pipe or reading from a mpsc or making network requests alongside. If it's cancelled, you get a broken file.

Of course, we could create dedicated documentation for this topic, but we simply cannot document every single foundational concept.

My humble proposal would be this:

Which mutex do I need?

As a rule of thumb, use the asynchronous mutex if:

• It is held across await points
• It is held for a long or unbound time, so the worker thread is released for the meantime

Use the synchronous mutex if:

• This is a performance critical path and a contention is unlikely
• You're making a cancel safe future and an additional await point would jeopardise the correctness