Post

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

0 reposts1 like

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.

useful.storeuseful.store

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)

Looks like lock_tree, which was listed as prior art, was also based on the Fuchsia lock-ordering design. Hence, it seems lock-ordering (indirectly) was declared as prior art after all :)