WEBVTT 00:06.010 --> 00:12.190 So, guys, now, next, let us try to understand that how deadlock like situation can also happen due 00:12.190 --> 00:15.670 to inconsistent locking order of mutexes. 00:16.150 --> 00:22.690 So it is a very simple scenario that in your program there can be scenarios where a thread needs to 00:22.690 --> 00:24.520 lock multiple mutexes. 00:24.760 --> 00:30.850 So for example, you have a thread T1 in your program and in the execution flow of this thread. 00:30.880 --> 00:37.810 T1 Let us suppose that at point P1 the thread T1 has lock the mutex M1 right. 00:37.870 --> 00:43.900 And in future the thread wishes to lock another mutex m2. 00:43.930 --> 00:49.780 So let us say that at point p to the thread t1 locks another mutex m2. 00:49.810 --> 00:50.410 Right. 00:50.440 --> 00:56.800 It is very common scenario that a thread may wish to grant locks on multiple resources of a process. 00:56.800 --> 00:57.520 Right. 00:57.700 --> 01:03.790 So the order in which a given thread locks multiple mutexes actually matter, right? 01:04.060 --> 01:10.220 If the threads of a process locks the mutexes in the wrong or inconsistent order, it may lead to the 01:10.220 --> 01:11.480 problem of deadlock. 01:11.510 --> 01:14.780 So let us try to understand this with the help of an example. 01:14.960 --> 01:22.820 So let us suppose that in your program we have a thread T1 which is executing the function foo one and 01:22.820 --> 01:25.600 let us suppose that our program is multithreaded. 01:25.610 --> 01:30.350 Therefore we have a thread T2 which is executing a function F two. 01:30.380 --> 01:36.080 Now you can see that thread t1 locks the mutex one and then it locks the mutex. 01:36.080 --> 01:43.490 Two whereas thread t2 does exactly opposite, it locks the mutex two and then it locks the mutex one. 01:43.790 --> 01:48.350 So now let us try to understand that how it can lead to the problem of deadlock. 01:48.950 --> 01:53.210 Let us suppose that on a given CPU the thread T1 is executing. 01:53.210 --> 01:59.930 And let us suppose that in the execution flow of the thread t1 the thread T1 has successfully logged 01:59.930 --> 02:07.160 the mutex one but just before the thread t1 locks the second mutex context switching happens. 02:07.190 --> 02:12.670 The thread t1 is offloaded on the CPU and the thread t2 is loaded on the CPU. 02:12.680 --> 02:13.430 Right. 02:13.430 --> 02:17.060 So now it is the thread t2 which resumes the execution. 02:17.880 --> 02:22.190 Now as thread T2 executes in its execution flow. 02:22.200 --> 02:29.130 Let us suppose that the thread T2 has successfully logged the mutex two and then after executing some 02:29.130 --> 02:37.440 instruction I to the thread t2 tries to locks the mutex one right, but the mutex one is already locked 02:37.440 --> 02:44.550 by the thread t1 so it simply means that the thread t2 will be blocked at this line because mutex one 02:44.550 --> 02:46.800 is already locked by the thread t1. 02:47.790 --> 02:53.520 Now since the thread T2 has gone in the blocked state, your operating system will remove the thread 02:53.550 --> 02:58.320 T2 from the CPU and gives the CPU back to the thread t1. 02:59.360 --> 03:06.320 Now remember that T1 left the CPU before it actually invoked this locking of mutex two. 03:06.410 --> 03:12.350 Now, when the thread T1 resumes its execution, the very first thing the thread T1 will do is to try 03:12.350 --> 03:14.180 to get a lock on the two. 03:14.240 --> 03:15.050 Right. 03:15.080 --> 03:21.590 Remember last time the context switching happened when the thread t1 was executing instruction I two. 03:21.620 --> 03:22.340 Right. 03:22.490 --> 03:28.280 But now here at this point of time, you can see that the thread T1 is trying to lock a mutex two which 03:28.280 --> 03:31.640 is already locked by the thread t2 Right. 03:33.410 --> 03:38.030 So it simply means that thread T1 would also go in the blocked state. 03:39.560 --> 03:45.530 So now here you can see that the thread T1 and thread t2 both are in the blocked state and hence the 03:45.530 --> 03:48.050 situation of deadlock has happened. 03:48.320 --> 03:52.760 So we can conclude that the order of locking the mutexes must be preserved. 03:52.790 --> 03:57.230 It simply means that here the order of locking the mutex don't matter. 03:57.230 --> 04:02.690 But whatever the order of locking of the mutex you have chosen, same order should be followed throughout 04:02.690 --> 04:03.460 the code. 04:03.470 --> 04:04.700 Right here. 04:04.700 --> 04:08.720 The thread t1 is locking the mutex m1 followed by mutex m2. 04:08.750 --> 04:13.940 Here the thread t2 is locking the mutex m2 followed by mutex m1. 04:14.150 --> 04:19.340 So because as a developer you have chosen different order of locking of these murexes by two different 04:19.340 --> 04:19.990 threads. 04:20.000 --> 04:25.040 Therefore, your program has exposed to the error of deadlock. 04:25.790 --> 04:33.050 If you have chosen the order of locking of mutexes in this order, say M1 followed by M2, then throughout 04:33.050 --> 04:39.920 your code, any thread must lock the mutexes in the same order that is M1 followed by M2. 04:39.950 --> 04:40.760 Right. 04:41.000 --> 04:46.280 If you take care of this ordering of locking the mutexes, then that lock would not occur. 04:46.310 --> 04:51.440 Then the next point says that it is recommended to unlock the mutex in the order. 04:52.370 --> 04:58.160 So here are coming back to this example that the thread T1 had logged the mutex M1 followed by locking 04:58.160 --> 04:59.540 the M2. 04:59.570 --> 05:06.170 It simply means that when your thread T1 is done with these mutexes, then it should unlock this mutex 05:06.170 --> 05:09.260 in the reverse order that is at point P3. 05:09.260 --> 05:17.810 It should unlock the mutex m2 first and then at point P4 it should unlock the mutex. 05:17.810 --> 05:19.690 M1 right. 05:19.700 --> 05:24.650 That is most recent lock mutex must be released first. 05:24.650 --> 05:25.370 Right? 05:25.880 --> 05:31.820 And if you notice all the four necessary conditions that we discussed in the previous lecture video, 05:31.820 --> 05:38.000 which are the prerequisite conditions for the deadlock to occur, are also true in this example. 05:38.000 --> 05:44.030 So remember, while deploying Mutexes and controlling the thread synchronization using Mutexes as a 05:44.030 --> 05:48.230 developer or programmer, the order of locking of the Mutexes doesn't matter.