# Tokio Authors - Shared state (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/57072820) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Tokio Authors]] **Full Title**:: Shared state **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [tokio.rs](https://tokio.rs/tokio/tutorial/shared-state) **Host**:: [[tokio.rs]] **Highlighted**:: [[2025-12-25]] **Created**:: [[2025-12-27]] ## Highlights - As a rule of thumb, using a synchronous mutex from within asynchronous code is fine as long as contention remains low and the lock is not held across calls to `.await`. ([View Highlight](https://read.readwise.io/read/01kdaj566agj5w4f5pjv645y4x)) ^969691557 - The primary feature of the Tokio mutex is that it can be held across an `.await` without any issues. ([View Highlight](https://read.readwise.io/read/01kdaj9sqaz47ah41w5v3h5yja)) ^969691641 - If contention on a synchronous mutex becomes a problem, the best fix is rarely to switch to the Tokio mutex. ([View Highlight](https://read.readwise.io/read/01kdajepyepbvccxxfjzzbqhmk)) ^969691730 - The [dashmap](https://docs.rs/dashmap) crate provides an implementation of a more sophisticated sharded hash map. You may also want to have a look at such concurrent hash table implementations as [leapfrog](https://docs.rs/leapfrog) and [flurry](https://docs.rs/flurry), the latter being a port of Java's `ConcurrentHashMap` data structure. ([View Highlight](https://read.readwise.io/read/01kdajgnvt081f55wqsbdjndem)) ^969691923