Hrm. I'm not immediately impressed by the "Level<>" construct. That feels like a lot of new cognitive burden. It's also not at all obvious to me that multiple levels of mutex is a common pattern? I'm not sure I've ever encountered a situation where locking Account also and always requires locking Config? Heaven help you if you have 3 or more levels.

I dunno. I appreciate the opposition to "just be careful". But this feels to me like it's inducing bad design patterns. So it feels like it's wandering down the wrong path.

▲

wrs 6 hours ago | parent [-]

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...

▲

forrestthewoods 4 hours ago | parent [-]

I'm aware.

I'd be curious to hear the authors reason to not prefer a LockSet everywhere.

	▲	expede an hour ago \| parent [-]
		(Author here) it depends on your use case. If you need to incrementally acquire locks, then levels are helpful. A place where this comes up is if you need to read a value out of one lock, and need to pick what to lock next based on that without releasing the first one. 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 level 1, and get even the level can be omitted thanks to a default type parameter. Levels have no runtime cost, so sidestepping them is free. This lets you live in a atomic-locks only world, and if you later find that you need incremental locks later, you can add more levels then :)