Async locks are bad

[mickvandijke]

After pounding my head for two weeks on trying to benchmark our async function that handles the addition and updates of torrents, and somehow not finding anyone else with the same problem or a solution. I came to the realization that perhaps that function shouldn't be async at all.

Oftentimes we use tokio::sync::Mutex & tokio::sync::RwLock for our lock as these are async compared to the std library's sync locks. And async is faster right? Well apparently, no. The overhead of switching tasks on worker threads when awaiting on an async lock is relatively a lot compared to just blocking the thread and using a sync lock.

Ok, that is cool and all, but you can't use sync locks in tokio tasks (which every client connection basically is in our case), so how do we make it work? The Tokio docs have a nice answer for that: https://tokio.rs/tokio/tutorial/shared-state#holding-a-mutexguard-across-an-await

So should we try and use sync locks instead of async locks now as much as possible? Yes I think so. Not only should it be faster, it would also make it easier for us to test and benchmark the synchronous code.

Other useful resources:

• https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/alan_thinks_he_needs_async_locks.html

Relevant issues:

• Optimize torrent/peers list reading and writing by breaking up the tracker.torrents field into smaller pieces #495
• Benchmark Tracker.update_torrent_with_peer_and_get_stats performance using Criterion #496

[josecelano]

More links

• https://ryhl.io/blog/async-what-is-blocking/