Compile time lock ordering approach to deadlocks

While rust can guarantee no data races in safe code, it can't avoid deadlocks. As systems grow large and multiple locks are involved, these become more likely, as expressed in the dining philosophers problem.

I'm somewhat surprised that I haven't seen any discussion of addressing this issue in rust. The way I'm most familiar with solving this is through a lock ordering policy. After poking around a bit, I think it's possible to enforce much of this at compile time with the typestate pattern. Here's a small proof-of-concept*.

Does this seems like a reasonable approach? How do others address this issue?

* There's a small hole in that dropping ABGuard may drop a before b, but I think that could be addressed by making the fields Options and implementing Drop for ABGuard manually; it just makes things uglier in a way that didn't seem necessary for the proof of concept.

1 Like

Is nobody else working in a system with a multiple locks such that lock ordering is an issue?

I do know of other people who are finding themselves in such situations. It's just that, from when I've been reading their stuff, their preferred solution is to use concurrency primitives like data parallelism, and message passing with session types, which are not only deadlock-free-by-construction, but also a lot easier to design in ways that have high throughput and that can be freely scaled up and down to more or fewer threads.

1 Like