What makes async mutex more expensive than sync mutex?

[parasyte]

You'll have to forgive me, but I haven't seen any claims that the cost is much higher. Just that it follows that having a mutex anywhere means that mutual exclusion is happening (by definition) and therefore all of the usual suspects apply WRT contention and whatnot.

@taesookim

If one argues the async version incurs much higher expense during acquire, I'd like example programs with profiling data to support this argument.

Same, but I haven't seen any such claims nor data to support them.

@taesookim

OTOH in case the semaphore cannot be locked at once, yielding is much safer than blocking because blocking may introduce deadlock. This can easily lead to bugs when a programmer later inserts an await in the mutex scope, unaware of it.

Can you elaborate on this? I can't tell if you are speaking of the use of a sync Mutex within the async semaphore, or a hypothetical situation involving a user deciding to use a sync Mutex in their own async code. For the former, the Mutex is well-abstracted and callers do not have direct access to it. We can also trust that the Tokio maintainers are aware of the pitfalls and can navigate them safely.

@taesookim

I still don't have intuition why the std mutex guard is not Send

It's just because various platforms have certain thread-safety requirements and Rust's standard library (abstracting over many platforms) needs to address these concerns with a lowest common denominator, Namely that if any platform does not allow a mutex to be unlocked on a thread that did not lock it, none of them can. More details on this aspect here:

Example of a type that is not Send? - help - The Rust Programming Language Forum (rust-lang.org)

For a more realistic example, it turns out that MutexGuard is not Send , since for the definition of MutexGuard to be maximally portable, it needs to support the POSIX API of pthreads , which states that a lock can only be released from within the thread where it was created.