The idea that Mutex<T> owns T and provides access to T only when locked is a really nice design, but... Does it solve the case here? The two locks ordered by t

The idea that Mutex<T> owns T and provides access to T only when locked is a really nice design, but... Does it solve the case here? The two locks ordered by the address check are otherwise unordered, i.e., one is not inherently owned by the other. One could imagine the same data structure in a Rust program: a vector of runqueues, all on equal footing, and the programmer wants to lock an arbitrary pair (i, j) of them. This would have to look something like: { let mut guard1 = locks[i].lock().unwrap(); let mut guard2 = locks[j].lock().unwrap(); do_work(*guard1, *guard2); } And you have the same problem as this post addresses: we need a total order over indices (e.g., ensure i < j) to prevent deadlock.