Each lock has an associated name. If you have locks for separate purposes, you have separate names. If you need to grab multiple locks before processing a single task, I would suggest looking for a design that doesn't need it. If there is no other way, then acquring each like in a defined order would still work.
This is one area where code reuse bites us and I think this is why you see so many systems starting to resemble functional code principles.
There are many code bases where you delegate an action to a module that goes out and modifies state (or doesn't) based on its own rules. Composing these things becomes challenging.
It leads to situations where verbs that sound like they should be side effect free are unknowingly causing an avalanche of updates behind the scenes.
And when two calls can touch the same objects in a different order (eg, when you have many-to-one relationships), then you are up a creek without a paddle.
Comments
Each lock has an associated name. If you have locks for separate purposes, you have separate names. If you need to grab multiple locks before processing a single task, I would suggest looking for a design that doesn't need it. If there is no other way, then acquring each like in a defined order would still work.
This is one area where code reuse bites us and I think this is why you see so many systems starting to resemble functional code principles.
There are many code bases where you delegate an action to a module that goes out and modifies state (or doesn't) based on its own rules. Composing these things becomes challenging.
It leads to situations where verbs that sound like they should be side effect free are unknowingly causing an avalanche of updates behind the scenes.
And when two calls can touch the same objects in a different order (eg, when you have many-to-one relationships), then you are up a creek without a paddle.