3 ms·

> Rust is race condition free, but not deadlock free. It needs a static deadlock analyzer, one that tracks through the call chain and finds that lock A is locke

> Rust is race condition free, but not deadlock free. It needs a static deadlock analyzer, one that tracks through the call chain and finds that lock A is locked before lock B on path X, while lock B is locked before path A on path Y. That sounds like a great idea. Something in the style of lockdep, that (when enabled) analyzes what locks are currently held while any other lock is taken, and reports any potential deadlocks (even if they haven't actually deadlocked). That would require some annotation to handle cases of complex locking, so that the deadlock detection knows (for instance) that a given class of locks are always obtained in address order so they can't deadlock. But it's doable.

wrsh07 3y ago
Google has acquired before: https://abseil.io/docs/cpp/guides/synchronization#thread-annotations https://abseil.io/docs/cpp/guides/synchronization#thread-ann... It's quite nice, but for cpp not rust
elabajaba 3y ago
There's tracing-mutex that builds a dag of your locks when you acquire them and panics (at runtime) if it could deadlock: https://github.com/bertptrs/tracing-mutex https://github.com/bertptrs/tracing-mutex parking_lot has a deadlock detection feature for when you deadlock that iirc tells you what deadlocked (so you're not trying to figure it out with a debugger and a lot of time) https://amanieu.github.io/parking_lot/parking_lot/deadlock/index.html https://amanieu.github.io/parking_lot/parking_lot/deadlock/i... I also just found out about https://github.com/BurtonQin/lockbud https://github.com/BurtonQin/lockbud which seems to detect deadlocks and a few other issues statically? (seems to require compiling your crate with the same version of rust as lockbud uses, which from the docs is an old 1.63 nightly build?)
nine_k 3y ago
I wonder if locks may have some thread-local registry, at least in debug builds. If locks can be numbered or otherwise ordered, it would be easy to enforce a strict order of taking locks and an inverse strict order of releasing them, by looking up in the registry which locks your thread is currently holding. This would prevent deadlocks. This, of course, would require to have an idea of all the locks you may want to hold, and their relative order (at least partial), as Dijkstra described back in the day. But thinking about locks is ahead of time is a good idea anyway.

wrsh07 3y ago

Google has acquired before: https://abseil.io/docs/cpp/guides/synchronization#thread-annotations https://abseil.io/docs/cpp/guides/synchronization#thread-ann... It's quite nice, but for cpp not rust

elabajaba 3y ago

There's tracing-mutex that builds a dag of your locks when you acquire them and panics (at runtime) if it could deadlock: https://github.com/bertptrs/tracing-mutex https://github.com/bertptrs/tracing-mutex parking_lot has a deadlock detection feature for when you deadlock that iirc tells you what deadlocked (so you're not trying to figure it out with a debugger and a lot of time) https://amanieu.github.io/parking_lot/parking_lot/deadlock/index.html https://amanieu.github.io/parking_lot/parking_lot/deadlock/i... I also just found out about https://github.com/BurtonQin/lockbud https://github.com/BurtonQin/lockbud which seems to detect deadlocks and a few other issues statically? (seems to require compiling your crate with the same version of rust as lockbud uses, which from the docs is an old 1.63 nightly build?)

nine_k 3y ago

I wonder if locks may have some thread-local registry, at least in debug builds. If locks can be numbered or otherwise ordered, it would be easy to enforce a strict order of taking locks and an inverse strict order of releasing them, by looking up in the registry which locks your thread is currently holding. This would prevent deadlocks. This, of course, would require to have an idea of all the locks you may want to hold, and their relative order (at least partial), as Dijkstra described back in the day. But thinking about locks is ahead of time is a good idea anyway.