Comment by wrs
12 hours ago
Lock ordering is indeed a common pattern to avoid deadlocks. I learned it in school in the 80's and MIT teaches it today. [0]
[0] https://web.mit.edu/6.005/www/fa15/classes/23-locks/#deadloc...
12 hours ago
Lock ordering is indeed a common pattern to avoid deadlocks. I learned it in school in the 80's and MIT teaches it today. [0]
[0] https://web.mit.edu/6.005/www/fa15/classes/23-locks/#deadloc...
I'm aware.
I'd be curious to hear the authors reason to not prefer a LockSet everywhere.
(Author here) it depends on your use case. If you need to incrementally acquire locks, then levels are helpful -- you can't do that with LockSets on their own. A place where this comes up is if you need to read a value out of one lock, and pick what to lock next based on that without releasing the first one, and then modify both. Of course you should think twice when doing this but when you need it, you REALLY need it.
Opting out of lock levels was a design goal. By default all locks are are Level1, so the level can be omitted thanks to the default type parameter filling it in for you. Levels have no runtime cost, so sidestepping them is free. This lets you live in an atomic-locks only world if you want, and if you later find that you need incremental locks, you can add more levels at that time :)
[EDIT: fixing autocorrect typos when I got back to my laptop]
Interesting example. Thanks for reply!