Avoiding deadlock is obviously something we would want to ensure. In addition to the points covered in the Locking guidelines section, there is one more key point, which is that the order in which multiple locks are taken matters; keeping the lock ordering consistent throughout will provide protection against deadlocks.

To understand why, let's re-look at the ABBA deadlock scenario we just covered (refer to the preceding table). Look at the table again: notice that thread A takes lock L1 and then attempts to take lock L2, while thread B does the opposite. We shall now represent this scenario, but with a key caveat: lock ordering! This time, we shall have a lock ordering rule; it could be as simple as this: first, take lock L1, and then take lock L2:

lock L1 --> lock L2

With this lock ordering in mind, we find the scenario could play out as follows:

The key point here is that both threads attempt to take locks in a given order; first L1, and then L2. In the preceding table, we can visualize a case in which thread B obtains the locks first, forcing thread A to wait. This is completely fine and expected; no deadlock occurring is the whole point.

The precise ordering itself does not really matter; what does matter is the fact that the designers and developers document the lock ordering to be followed and stick to it.

So, looking back at our first table, we can now clearly see that the deadlock occurred because the lock ordering rule was violated: thread B took lock L2 before taking lock L1!