Post

Surelock by @expede.wtf is a really fascinating and impressive use of the Rust type system to prevent deadlocks at compile time. I will 100% be using this for future Rust projects. notes.brooklynzelenka.com/Blog/Surelock

Unfortunate github.com/akonradi/loc... wasn’t included as prior art as well. I have vibe coded something similar based on it, with a proc macro for specifying the DAG.

Also this don’t work for runtime locks. E.g Map<string, Lock<value>>. I came up with the “OrderedLock”. You specify it logically at compile time to fit into the DAG. At runtime each lock has an ordered key. Then it asserts ordered acquisition - which fits within compile time enforced ordering

Seems like surelock should handle runtime locks? Or do you mean the lock-ordering crate? I think @expede.wtf wasn't trying to list all prior art, just the ones that influenced the design.

The LockSet idea is really cool, but misses out on some flexibility. My understanding is you pre-declare the locks you need (LockSet does ordering internally). But it’s common to not know what locks you need upfront. For this the application needs to be in control of ordering.

Yes exactly! This is what LockSet accounts for. It acquires multiple locks *atomically* and Surelock handles the ordering under the hood. Lock IDs only have to be stable and unique to avoid deadlocks, but as a tradeoff you must acquire all of the locks at once.

Surelock *additionally* lets you declare order for groups of locks in advance by setting them at a Level<_>. They'll default to Level<1> (you can omit the type param). This coarse mechanism allows you to acquire multiple LockSets incrementally (each LockSet atomically, but then several in sequence)

(Did I understand the concern correctly, and does that explanation help?)

Not exactly, for _runtime_ ordering within a level, I am suggesting a slight adjustment for a more flexible API. Let the application provide custom ordering - thus (with less safety) now one can acquire locks one at a time with its known order with panic safety. `LockSet` can be a safer API on top.

To demonstrate this I open sourced my version (it implements the lock guard suggestion from the original lock-ordering gh issue + ordered map). See for ordered map use case codeberg.org/snowytrees/l... I think you can hide this from non-advanced users by doing a default impl with auto-ordering.

Under the hood this works by overloading the ZST lock guards, the ordered lock guard stores the ZST + the last key. Thus the guards represent a "stack" of ordering keys. Allowing for releasing (popping) and acquiring (pushing) ordered values into the runtime lock stack. codeberg.org/snowytrees/l...

Interesting approach! Does this mean that users can pick their own lock IDs for fine-grained ordering in addition to having them automatically assigned? Glancing through the code, I think one of the tradeoffs is that lock acquisition is not guaranteed to succeed, is that right?