So, guys, now, next, let us try to understand that how deadlock like situation can also happen due
to inconsistent locking order of mutexes.
So it is a very simple scenario that in your program there can be scenarios where a thread needs to
lock multiple mutexes.
So for example, you have a thread T1 in your program and in the execution flow of this thread.
T1 Let us suppose that at point P1 the thread T1 has lock the mutex M1 right.
And in future the thread wishes to lock another mutex m2.
So let us say that at point p to the thread t1 locks another mutex m2.
Right.
It is very common scenario that a thread may wish to grant locks on multiple resources of a process.
Right.
So the order in which a given thread locks multiple mutexes actually matter, right?
If the threads of a process locks the mutexes in the wrong or inconsistent order, it may lead to the
problem of deadlock.
So let us try to understand this with the help of an example.
So let us suppose that in your program we have a thread T1 which is executing the function foo one and
let us suppose that our program is multithreaded.
Therefore we have a thread T2 which is executing a function F two.
Now you can see that thread t1 locks the mutex one and then it locks the mutex.
Two whereas thread t2 does exactly opposite, it locks the mutex two and then it locks the mutex one.
So now let us try to understand that how it can lead to the problem of deadlock.
Let us suppose that on a given CPU the thread T1 is executing.
And let us suppose that in the execution flow of the thread t1 the thread T1 has successfully logged
the mutex one but just before the thread t1 locks the second mutex context switching happens.
The thread t1 is offloaded on the CPU and the thread t2 is loaded on the CPU.
Right.
So now it is the thread t2 which resumes the execution.
Now as thread T2 executes in its execution flow.
Let us suppose that the thread T2 has successfully logged the mutex two and then after executing some
instruction I to the thread t2 tries to locks the mutex one right, but the mutex one is already locked
by the thread t1 so it simply means that the thread t2 will be blocked at this line because mutex one
is already locked by the thread t1.
Now since the thread T2 has gone in the blocked state, your operating system will remove the thread
T2 from the CPU and gives the CPU back to the thread t1.
Now remember that T1 left the CPU before it actually invoked this locking of mutex two.
Now, when the thread T1 resumes its execution, the very first thing the thread T1 will do is to try
to get a lock on the two.
Right.
Remember last time the context switching happened when the thread t1 was executing instruction I two.
Right.
But now here at this point of time, you can see that the thread T1 is trying to lock a mutex two which
is already locked by the thread t2 Right.
So it simply means that thread T1 would also go in the blocked state.
So now here you can see that the thread T1 and thread t2 both are in the blocked state and hence the
situation of deadlock has happened.
So we can conclude that the order of locking the mutexes must be preserved.
It simply means that here the order of locking the mutex don't matter.
But whatever the order of locking of the mutex you have chosen, same order should be followed throughout
the code.
Right here.
The thread t1 is locking the mutex m1 followed by mutex m2.
Here the thread t2 is locking the mutex m2 followed by mutex m1.
So because as a developer you have chosen different order of locking of these murexes by two different
threads.
Therefore, your program has exposed to the error of deadlock.
If you have chosen the order of locking of mutexes in this order, say M1 followed by M2, then throughout
your code, any thread must lock the mutexes in the same order that is M1 followed by M2.
Right.
If you take care of this ordering of locking the mutexes, then that lock would not occur.
Then the next point says that it is recommended to unlock the mutex in the order.
So here are coming back to this example that the thread T1 had logged the mutex M1 followed by locking
the M2.
It simply means that when your thread T1 is done with these mutexes, then it should unlock this mutex
in the reverse order that is at point P3.
It should unlock the mutex m2 first and then at point P4 it should unlock the mutex.
M1 right.
That is most recent lock mutex must be released first.
Right?
And if you notice all the four necessary conditions that we discussed in the previous lecture video,
which are the prerequisite conditions for the deadlock to occur, are also true in this example.
So remember, while deploying Mutexes and controlling the thread synchronization using Mutexes as a
developer or programmer, the order of locking of the Mutexes doesn't matter.