Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
toot.cat is one of the many independent Mastodon servers you can use to participate in the fediverse.
On the internet, everyone knows you're a cat — and that's totally okay.

Administered by:

Server stats:

419
active users

toot.cat: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.0-alpha.4+glitch.30f69ecff

Public

Never use Tokio mutexes. From a guide I'm in the middle of writing:

Don’t use tokio::sync::Mutex (Or, shared mutable state is bad.) Tokio comes with a Mutex that is specifically designed for use in asynchronous contexts. The official recommendation is to prefer std::sync::Mutex if locks are not held across await points, and tokio::sync::Mutex only if locks are held across awaits. However, given that: Almost all uses of mutexes are to temporarily violate code invariants within a critical section, restoring them by the end of the operation. Mutexes are almost always shared between futures (otherwise why would a mutex be used at all), which means that the "cancellation blast radius" of a future holding a mutex extends to other futures. std::sync::Mutex has a notion of lock poisoning. Tokio’s mutexes don’t[12]. What this suggests is that if a future that is currently holding on to a mutex is cancelled, the state guarded by the mutex is likely invalid. This is such a big problem that this guide recommends avoiding tokio::sync::Mutex to the greatest extent possible. Alternatives to Tokio mutexes The main alternative to a Tokio mutex is a message-passing design, as described in this Tokio tutorial. Rather than having futures access some common shared state, this scheme has a single manager task that has full (non-shared) ownership of this state. This task receives requests in serial order, via an MPSC channel, and sends responses over (typically) oneshot channels.
Another alternative is to switch to std::sync::Mutex if possible, and not hold locks across await points. In many cases this can be done through some kind of code rearrangement or a few judicious clones. If you really must use a Tokio mutex It isn’t impossible to write correct code that manages Tokio mutexes, just very difficult. Some approaches you could take: Declare that your code isn’t cancel-safe. Ensure that invariants are always restored between await points. Having invalid state between await points is okay[13]. Clean up invalid state at the start of every critical section. All of these options require you to think a lot, which isn’t true for any of the recommended suggestions.
*

@rain ooof. I assume this applies to futures::lock::Mutex, too?...

·Public·Web
0boosts·0favorites
Public

@zkat Yes, looks like it. Basically async and mutexes just don't play along, because futures can always be cancelled (dropped) at any await point

Public

@rain @zkat

Given a choice I'd reach for tokio's Mutex before futures::lock::Mutex -- they both have the same issue Rain describes (where if you drop them while invariants are violated, you get bugs later), but tokio's is at least fair (making starvation harder).

Public

@rain @zkat shouldn’t the drop of the task imply a drop of the mutexguard?

*
Public

@baloo @zkat Yes, the problem is that if invariants are violated in the middle of the critical section (very normal for mutexes) then the mutex silently unlocks and the invariants stay violated

Public

@rain @zkat ha, good point! I was only looking for poisoned mutex

Public

@rain @zkat removing the Unpin blanket implementation should make sure it can't cross await points right?

Public

@baloo @zkat That would defeat the point of tokio mutexes though, if you don't want to cross await points then you can just use std mutexes

SearchLive feeds
About