Surelock aims to make Rust deadlocks a compile-time error

If your code compiles, it doesn’t deadlock. That is the promise Brooklyn Zelenka put at the center of surelock, a pre-release Rust library meant to turn one of concurrency’s nastiest failures into a compile-time problem.

The pitch lands because Rust still has a gap here. The language’s ownership and type system move many concurrency errors out of runtime, but the Rust book still warns that multithreaded code can hit deadlocks, with two threads waiting on each other and neither able to continue. Surelock tries to close that liveness hole with types, not discipline, reviews, or a late-night incident response.

Its design splits the problem in two. Same-level locks are acquired atomically in deterministic order through a LockSet, while cross-level locks are acquired incrementally with compile-time ordering enforced through Level<N>. Zelenka says the public API is entirely safe, with unsafe code confined to raw mutex internals. That matters because it is a stronger claim than “we caught a bug in testing.” It says deadlock freedom should be something the compiler can help prove.

The project also arrives with a practical bias that will matter to embedded and infrastructure teams: it is no_std compatible and has no required runtime dependencies. For Rust systems that run close to the metal, or in places where extra runtime machinery is a burden, that keeps the idea in the realm of possible adoption instead of pure theory.

Surelock is not the only attempt to make deadlocks less mysterious. A 2024 arXiv paper, Static Deadlock Detection for Rust Programs, targets deadlock patterns including double lock, conflict lock, and condition-variable-related deadlocks. A newer paper, Two Birds One Stone: Effective Static Detection of Resource and Communication Deadlocks, says its RcChecker tool found seven previously undiscovered issues in real-world Rust applications, including two resource deadlocks and five communication deadlocks. The direction of travel is clear: the ecosystem is getting better at spotting these failures, even after the fact.

The harder question is whether surelock’s guarantees survive contact with everyday code. One community reaction raised a familiar edge case: if different threads can acquire the same shared locks in different valid DAG orders, the compiler may still accept a program that deadlocks in practice. That is the fault line surelock now has to cross, between elegant type-level modeling and the messy reality of lock graphs, partial orders, and human-written concurrent code.

For Rust developers, the attraction is obvious. Memory safety was the first great promise. Surelock is trying to make liveness feel like something the type system can finally police too.