> The lock
ordering rules had become too complicated and this was getting us too many
transaction restarts, so I stole the standard technique from databases
Any details/links that explain this? The article seems to suggest that they used to detect the deadlock as it was about to happen, and then abort everything and retry. This doesn't seem too different from "when they happen". What is the optimization?
Previously, we were checking for lock ordering violations. But a lock ordering violation isn't a deadlock, just a potential deadlock.
Checking for a lock ordering violation is simpler because you only have to look at data structures for the current thread - you're just looking at what other locks the current thread is holding.
To check for a deadlock you have to do a full DFS of threads blocked on locks held by other threads, looking for cycles. Quite a bit trickier, but it was well worth it :)
Thanks for the explanation. Very interesting! I assume you only do the DFS when you detect a lock ordering violation? So if there is the potential for a deadlock you'll do extra work to make sure that you're actually deadlocked before aborting?
What is the standard technique from databases?