[deleted]
Rust's Sneaky Deadlock With `if let` Blocks
81–85 of 85 posts
Re: Rust's Sneaky Deadlock With `if let` Blocks
#82Earlier quoted context omitted.
Dropping a lock guard in rust requires you to have already dropped the borrow — the shared memory under lock is only accessible through the guard, and you can’t drop an object if you have a reference to it. This is not true in C, where you can reference the shared memory after the lock is released.
> This is not true in C, where you can reference the shared memory after the lock is released. technically yes but practically this is nearly always programmer bug to bypass a lock
That is the point — this is (another) example of a programmer bug that C allows that Rust does not.
Re: Rust's Sneaky Deadlock With `if let` Blocks
#83Earlier 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…
[deleted]
Re: Rust's Sneaky Deadlock With `if let` Blocks
#84Earlier 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…
I'm not convinced, because you're conflating too many things here. Ownership and borrow checking are always compile time concepts. There is no language runtime involved. If you think of C as a magic language then start today and get that idea out of your head.
If locking and unlocking semantics are a good fit for whatever you are doing, then you can just do a lock implementation setting whatever memory mapped registers you need. There is no constraint here whatsoever.
Nobody is advocating for separate atomics in every little object in Rust. That's a Java idea that failed miserably long before Rust was even around.
Re: Rust's Sneaky Deadlock With `if let` Blocks
#85Earlier quoted context omitted.
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.
From an API design point of view, I would always encapsulate the logically mutable state in some type `Foo`, even if it doesn't literally own the memory, and then expose a safe API using `Mutex `. Idiomatically, you would then make `Foo::new_unchecked()` unsafe, with the precondition that nobody else is accessing the same external resource, and that `Foo::new_unchecked()` is only ever called once.
Yep, it's nice to use marker types for this kind of thing.