Hacker News Reader

Comment by maplant | Hacker News Reader

> using a normal std Mutex within an async environment is an antipattern and should not be done

This is simply not true, and the tokio documentation says as much:

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

https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html#wh...

View on HN

I think that’s a dangerous recommendation and ignores the consequence of doing this within a single threaded reactor (your app will hang permanently if the lock is contended) or assumes you won’t have N threads trying to acquire this lock where N is the size of your thread pool which is entirely possible on a heavily accessed server if the core state that needs to be accessed by every request is locked with said mutex.

If you're using a single threaded reactor you don't need a mutex at all; a Rc<RefCell<_>> will do just fine. And if you want other tasks to yield until you're done holding the borrow, the solution is simple: don't await until you're done. https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html...

there are absolutely situations where tokio's mutex and rwlock are useful, but the vast majority of the time you shouldn't need them

As you know Rc<RefCell> won't work for a data structure that's being accessed by other threads (e.g. spawn_blocking or explicitly accessed threads). Just because you are using the single-threaded reactor does not mean you don't have other threads to access the data.

It seems like you've found a very specific situation where tokio's Mutex is helpful but it is simply not common to be structuring an async rust application with a single threaded reactor and copious uses of spawn blocking. The advice to go for the std Mutex first is generally good

Reply on news.ycombinator.com