2

I am implementing a feature using the async/await based Tokio and Rust 1.39.0. I understand there can be performance implications with using the regular Mutex from within an async context, but are there any other possible effects? For example, I remember reading somewhere it can lock up the thread pool/runtime or hang the system.

For context, the rest of our system is written in a synchronous way. I am looking at implementing the network facing part using the latest Tokio which would use tokio::sync::Mutex and friends. It is possible that the asynchronous network component calls into the synchronous parts which try to take the sync::Mutex.

Some options:

  1. Separate these parts via message passing
  2. Change parts of the rest of the system to be async aware, which would be a big undertaking.

I would like to avoid both if possible.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
rusty
  • 929
  • 1
  • 5
  • 10
  • It looks like your question might be answered by the answers of [What is the best approach to encapsulate blocking I/O in future-rs?](https://stackoverflow.com/q/41932137/155423). If not, please **[edit]** your question to explain the differences. Otherwise, we can mark this question as already answered. – Shepmaster Nov 14 '19 at 00:43
  • Thanks for the link, gives a good background. That discussion focuses on blocking for a long running operation. My case is little different, but still about blocking: blocking on sync locks. The code is designed to hold these for minimal time(e.g) update a HashMap under lock. – rusty Nov 14 '19 at 18:24
  • So IIUC, if we make sure the per-CPU executor threads don't block(or block for short/reasonable duration), we should be fine. Does this assertion sound right? – rusty Nov 14 '19 at 18:26

0 Answers0