3 ms·
If you are always going to grab locks in the same order, doesn't that mean you only need one lock?
by jeremyjh 11y ago
If you are always going to grab locks in the same order, doesn't that mean you only need one lock?
- JoeAltmaier 11y agoDifferent places in the code may take a different set of locks. Its about granularity, letting different threads continue while different locks are held.
- michaelochurch 11y agoIt works as long as you know which locks you need in advance. You'll get much better concurrency than with the one-lock model when there's a low probability that two processes need any of the same locks (e.g. locking a whole table vs. locking individual records). It fails you if you have a monadic rather than applicative requirement on the computation; that is, if intermediate computations can require you to take more locks that you couldn't have predicted needing in advance. In that case, you're going to need a transactional-memory system that can abort and retry computations, and that is powerful but hard to get right.