use std::sync::Mutex;
fn main() {
let mutex = Mutex::new(());
let mut guard = mutex.lock().unwrap();
guard = mutex.lock().unwrap();
}
In my understanding, when you reassign guard, Rust calls drop() on the old MutexGuard value currently held in guard, which releases the lock, so the next mutex.lock().unwrap() shouldn't block. But why does it still block?
Yes, and the only thing I forgot about in my answer was the reassignment. I'm still pretty sure it's dropped at the end of the scope, after the second guard has been dropped.
More likely something like Malbolge. I read somewhere that each time we remember something, the memory gets "replaced" with a memory of us remembering it. Don't quote me on it, though. Anyway, this is off topic. Thank you both for pointing out my error. I'm just a neural network, after all.
If guard were a dereference (not a local variable), then it'd have to drop after the assignment, because dropping before the assignment wouldn't be panic-safe (the RHS might panic, and then you've got a dropped variable hanging out in memory. Oops.) I don't think we guarantee the order of operations for local variable reassignment.