Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's Sneaky Deadlock With `if let` Blocks

brooksblog.bearblog.dev

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Rust's Sneaky Deadlock With `if let` Blocks

#51

Post by nindalf »

ajross wrote: post #48
sunshowers wrote: post #16

Earlier quoted context omitted.

I think mutexes that own their data are genuinely much easier to reason about than mutexes that don't. In this case this is a Rust bug that will be fixed in the next edition: https://github.com/rust-lang/rust/issues/124085

That's arguably true, but only insofar as it makes sense to talk about a mutex "owning" "data". There are many kinds of data that can't be owned by the language runtime like this (think about async/shared/DMA buffers, register blocks on foreign hardware, memory-mapped database files), but that still clearly need synchronization. Even things like coarse-grained locks taken at the subsystem level (e.g. to avoid having…

Here’s what I understand from your comment, correct me if I’m wrong. You’re saying there is a runtime cost associated with a mutex/rwlock owning the data. And secondly, you think it isn’t possible to implement this pattern in other areas that need locking.

I don’t think either of those is true. Encoding the ownership in the type system makes things clearer, imposes a compile-time cost but not run-time cost. Also, there isn’t any magic in the stdlib implementation of Mutex and Rwlock other than implementing it natively for every OS. This means that it is possible to implement the pattern for the examples you gave.

Re: Rust's Sneaky Deadlock With `if let` Blocks

#53

Post by zacmps »

ajross wrote: post #48
sunshowers wrote: post #16

Earlier quoted context omitted.

I think mutexes that own their data are genuinely much easier to reason about than mutexes that don't. In this case this is a Rust bug that will be fixed in the next edition: https://github.com/rust-lang/rust/issues/124085

That's arguably true, but only insofar as it makes sense to talk about a mutex "owning" "data". There are many kinds of data that can't be owned by the language runtime like this (think about async/shared/DMA buffers, register blocks on foreign hardware, memory-mapped database files), but that still clearly need synchronization. Even things like coarse-grained locks taken at the subsystem level (e.g. to avoid having…

You can also use a mutex that doesn't own data in Rust if you need to.

Re: Rust's Sneaky Deadlock With `if let` Blocks

#54

Post by lodovic »

dathinab wrote: post #11
CJefferson wrote: post #8

Earlier quoted context omitted.

There are however many PRs about people ignoring the return values of pthread_mutex_lock(), or missing an unlock on one route through a function.

and nothing prevents you from explicitly dropping lock guards in rust either actually it's a common pattern in complicated multi threaded code or similar to require that

The rust compiler (or the rust-analyzer) directs developers to use mutexes or other guards, even in single-threaded code when the use case wouldn't strictly require it. Where we would get undefined behavior in C, we get deadlocks in rust. This forces developers to handle these cases, but this can be quite painful to implement, especially in embedded or no_std environments.

Re: Rust's Sneaky Deadlock With `if let` Blocks

#55

Post by sunshowers »

ajross wrote: post #48
sunshowers wrote: post #16

Earlier quoted context omitted.

I think mutexes that own their data are genuinely much easier to reason about than mutexes that don't. In this case this is a Rust bug that will be fixed in the next edition: https://github.com/rust-lang/rust/issues/124085

That's arguably true, but only insofar as it makes sense to talk about a mutex "owning" "data". There are many kinds of data that can't be owned by the language runtime like this (think about async/shared/DMA buffers, register blocks on foreign hardware, memory-mapped database files), but that still clearly need synchronization. Even things like coarse-grained locks taken at the subsystem level (e.g. to avoid having…

That is true, but I don't believe Rust imposes a cost here. The worst case degrades to a `Mutex` and then whatever's being guarded being managed separately.

Re: Rust's Sneaky Deadlock With `if let` Blocks

#56

Post by the_duke »

anderskaseorg wrote: post #18

Clippy already has an error for this pattern with Mutex. It should be trivial to extend it to cover RwLock. error: calling `Mutex::lock` inside the scope of another `Mutex::lock` causes a deadlock --> src/main.rs:5:5 | 5 | if let Some(num) = *map.lock().unwrap() { | ^ --- this Mutex will remain locked for the entire `if let`-block... | _____| | | 6 | | eprintln!("There's a number in there: {num}"); 7 | | } else { 8 |…

There are a lot of alternative lock implementations that are used all the time, with the most common ones probably being tokios RwLock/Mutex and parking_lot.

That lint won't help for those.

Re: Rust's Sneaky Deadlock With `if let` Blocks

#57

Post by Kab1r »

nindalf wrote: post #52
Kab1r wrote: post #32

I would call this a compiler bug

It’s getting fixed soon - https://github.com/rust-lang/rust/issues/124085

If the change is targeting a rust edition it's being treated as a feature/improvement not as a compiler bug. If there isn't a spec that explicitly says that this is expected behavior (and as far as I know there isn't a concrete spec for the rust language) it should be instead treated as a backwards compatible bug fix

Re: Rust's Sneaky Deadlock With `if let` Blocks

#58

Post by nlitened »

While I never dove deep into Rust, until now I have kinda naively expected for some reason that Rust's lifetimes and ownership model prevents these trivial deadlocks at compile time. Thinking about it now, there's no reason why it would. Still lots of footguns.

Also, from my experience, acquiring and releasing a mutex multiple times within a single code path feels to me like a smelly, subtly faulty code. Are there legitimate cases when it is inevitable and correct?

Re: Rust's Sneaky Deadlock With `if let` Blocks

#59

Post by simonask »

nlitened wrote: post #58

While I never dove deep into Rust, until now I have kinda naively expected for some reason that Rust's lifetimes and ownership model prevents these trivial deadlocks at compile time. Thinking about it now, there's no reason why it would. Still lots of footguns. Also, from my experience, acquiring and releasing a mutex multiple times within a single code path feels to me like a smelly, subtly faulty code. Are there le…

Yeah, intuitively Mutex is actually one of the tools that you use to negotiate with the borrow checker (it's one implementation of "interior mutability", allowing conversions from immutable to mutable borrows by taking the lock), so it is kind of by definition not something Rust can prevent, outside of lints and other static analysis.

I can't think of a use case for taking a mutex lock multiple times in a code path, but there is a common cache pattern with RwLock, where you have a "fast path" that only takes a read lock to perform a lookup, and then only take a write lock when inserting a new entry. In this case, you should be using an upgradable read lock, so there is technically a "re-lock" of the same RwLock on upgrade in the same codepath. This model does prevent deadlocks because of move semantics.

Re: Rust's Sneaky Deadlock With `if let` Blocks

#60

Post by vanviegen »

nlitened wrote: post #58

While I never dove deep into Rust, until now I have kinda naively expected for some reason that Rust's lifetimes and ownership model prevents these trivial deadlocks at compile time. Thinking about it now, there's no reason why it would. Still lots of footguns. Also, from my experience, acquiring and releasing a mutex multiple times within a single code path feels to me like a smelly, subtly faulty code. Are there le…

> I have kinda naively expected for some reason that Rust's lifetimes and ownership model prevents these trivial deadlocks at compile time.

It does in a way, as you'd generally do multi-threading using message passing (for which the borrow checker can verify thread-exclusive data access) instead of manual locking.

Post reply on HN