WEBVTT 00:05.280 --> 00:09.800 So guys, now, next obvious question that arises is how mutexes work. 00:09.810 --> 00:16.710 So the only goal of the mutex is to grant access to critical section to only one and only one thread 00:16.710 --> 00:18.140 of the process at a time. 00:18.150 --> 00:21.450 This is the sole purpose of using mutexes. 00:21.450 --> 00:22.200 Right? 00:22.830 --> 00:30.330 So Posix, APR or Posix standard provides a data type p thread mutex using which we can declare and 00:30.330 --> 00:32.610 define the mutex type objects. 00:32.610 --> 00:33.270 Right? 00:33.270 --> 00:40.290 So remember, it's a P thread T, it's a data type which is provided by Posix standards. 00:41.010 --> 00:45.780 Now consider a short program here which is represented by this function foo. 00:45.780 --> 00:51.960 And let us suppose that we have three concurrent threads, thread, T1 thread, T2 and T3. 00:51.960 --> 00:56.280 All these threads are executing concurrently inside a function foo. 00:56.280 --> 00:58.440 Now you can see that in the function foo. 00:58.440 --> 01:06.250 We have a critical section now without deploying any thread synchronization protection on the thread, 01:06.280 --> 01:13.480 T1 thread, T2 and T3 would going to execute inside this critical section in a concurrent manner. 01:13.480 --> 01:20.020 And we have already seen an example where the concurrent access of threads inside a critical section 01:20.020 --> 01:21.760 leads to several problems. 01:21.760 --> 01:29.590 So here what we are looking is to use this mutex object to provide mutual exclusivity to each of these 01:29.590 --> 01:35.320 threads t1, t2, T3 in relation to executing inside this critical section. 01:36.050 --> 01:41.880 Our end goal is that that only one thread at a time execute inside this critical section. 01:41.900 --> 01:42.610 Right. 01:42.620 --> 01:44.460 This is our main goal. 01:44.480 --> 01:50.930 So what we will going to do is that in order to provide mutual exclusivity of this critical section 01:50.930 --> 01:55.850 to each of these threads, we will going to protect this critical section. 01:55.850 --> 02:02.240 Or in other words, we will going to sandwich this critical section between the lock and unlock API 02:02.240 --> 02:03.140 calls. 02:03.970 --> 02:10.630 When we write p thread mutex lock, it simply means that whichever threads execute the instruction i1 02:10.660 --> 02:13.270 would going to lock this mutex. 02:13.570 --> 02:18.980 In other words, we say that that particular thread becomes the owner of this mutex. 02:19.000 --> 02:19.810 Right. 02:20.440 --> 02:28.210 So let us suppose that among these three threads T1, T2 and T3, it happens to be thread T1 which executes 02:28.210 --> 02:30.040 the instruction I1 first. 02:30.070 --> 02:35.230 It means that it is the thread t1 which becomes the owner of this mutex object. 02:35.800 --> 02:43.120 After locking the mutex, the thread T1 is now allowed to execute inside the critical section. 02:43.120 --> 02:43.870 Right. 02:44.200 --> 02:49.900 So whichever thread locks the mutex shall be able to enter into critical section. 02:50.080 --> 02:55.300 If a thread tries to lock already locked mutex, then that particular thread is locked. 02:55.330 --> 03:01.810 Now in this example, the thread T1 is already executing in the critical section and the thread T1 has 03:01.810 --> 03:09.620 already locked the mutex object, so it simply means that if the thread T2 and T3 tries to execute the 03:09.620 --> 03:18.140 instruction i1 that is, if the thread T2 and T3 tries to lock the same mutex object, then those threads 03:18.140 --> 03:20.060 would going to get blocked. 03:20.090 --> 03:27.830 So it simply means that here thread t2 and thread thread t3 would going to get into the blocked state. 03:29.360 --> 03:35.120 So you can see here that multiple threads may be blocked by the same mutex, as simple as that. 03:35.150 --> 03:41.930 Here you have only one mutex, but this mutex is able to block the thread t2 and thread T3. 03:43.550 --> 03:50.300 Next point says that when the thread exits out the critical section, it must unlock the mutex that 03:50.300 --> 03:51.230 it had locked. 03:51.260 --> 03:58.340 So you can see that when the thread T1 is finished with executing in the critical section, the thread 03:58.370 --> 04:01.810 T1 must unlock the mutex which it had locked earlier. 04:01.820 --> 04:02.600 Right. 04:03.290 --> 04:09.740 So it simply means that when the thread T1 exits out the critical section, the mutex object would going 04:09.740 --> 04:13.670 to be unlocked and we say that the mutex is now available. 04:14.120 --> 04:20.840 Now going further among many threads, waiting for the same mutex, in our example we have thread T2 04:20.840 --> 04:23.570 and T3 which were blocked by the mutex. 04:23.690 --> 04:24.380 Right. 04:24.380 --> 04:30.650 So among many threads which were waiting for the same mutex, mutex shall be granted to only one depending 04:30.650 --> 04:36.300 on several factors such as thread, priority or operating system scheduling policy, etcetera. 04:36.320 --> 04:37.060 Right. 04:37.070 --> 04:44.300 So in this example thread, T2 and T3 were blocked by the mutex, but now since the mutex has become 04:44.300 --> 04:50.390 available because the thread T1 has released the mutex, so either the mutex will be granted to thread 04:50.420 --> 04:53.570 T2 or it would be granted to thread T3. 04:53.600 --> 04:54.190 Right. 04:54.200 --> 05:00.380 We can't say which thread it will be, but we can say that only one out of these two threads would go 05:00.380 --> 05:01.610 in to lock the mutex. 05:01.610 --> 05:02.240 Right. 05:04.440 --> 05:09.900 So let us suppose that it is thread t2 which has been granted a lock to the mutex. 05:09.900 --> 05:14.300 So now it's time for the thread t2 to execute in the critical section. 05:14.310 --> 05:15.030 Right. 05:15.060 --> 05:18.540 While thread T3 stays blocked. 05:18.570 --> 05:25.170 Similarly, when the thread T2 leaves the critical section it will unlock the mutex object and now the 05:25.170 --> 05:30.350 mutex will be granted to the thread t3 which is still in the blocked state. 05:30.360 --> 05:31.080 Right. 05:31.710 --> 05:38.520 So this is how the mutex locking and unlocking is done by several threads when several threads compete 05:38.520 --> 05:40.020 for the same mutex. 05:40.530 --> 05:48.060 Now discussing the next point thread must not intentionally die when holding the mutex lock that mutex 05:48.060 --> 05:50.150 become unusable for forever. 05:50.160 --> 05:52.950 So in this example we discussed that thread. 05:52.980 --> 05:57.990 T1 was granted the mutex and the thread T1 entered into the critical section. 05:57.990 --> 05:58.620 Right. 05:58.650 --> 06:05.950 Now let us suppose that while executing the instruction i2 the thread t1 invokes p thread exit call. 06:07.980 --> 06:16.360 So it simply means that thread one has been terminated, but thread one did not unlock the mutex. 06:16.380 --> 06:23.150 It simply means that thread, T2 and T3 were going to stay blocked for forever. 06:23.160 --> 06:23.910 Right? 06:23.940 --> 06:29.320 In other words, thread 32 and thread T3 has entered into a deadlock situation. 06:29.340 --> 06:35.730 They are waiting to grant a lock on the mutex which is logged by a thread which do not exist. 06:35.760 --> 06:36.600 Right. 06:36.840 --> 06:43.590 There is no one to release a lock on this mutex and hence the thread t2 and threat T3 would go into 06:43.590 --> 06:45.330 stay blocked for forever. 06:46.080 --> 06:52.890 So always remember that whenever you terminate a thread you must ensure that thread T1 must not hold 06:52.890 --> 06:54.990 any mutex in the locked state. 06:56.350 --> 07:03.010 Use of mutexes cause threads to block and unblock more the blocking and unblocking of threads, more 07:03.010 --> 07:09.250 scheduling work overhead on operating system and hence poorer shall be the application performance. 07:09.910 --> 07:13.720 And the next point say is that bigger the size of the critical section. 07:13.720 --> 07:18.600 Here we have taken the critical section which is represented by instruction I two. 07:18.610 --> 07:23.770 But this critical section could be hundreds of or thousands of lines of code, right? 07:23.770 --> 07:28.600 So bigger the size of the critical section, larger the time the blocked threads would have to wait. 07:28.600 --> 07:29.290 Right. 07:29.290 --> 07:35.680 Because larger the size of the critical section means larger will be the time taken by the thread to 07:35.680 --> 07:38.380 finish executing that critical section. 07:38.440 --> 07:39.130 Right. 07:39.130 --> 07:43.450 And it would lead to poorer performance of the application as well. 07:43.450 --> 07:44.070 Right. 07:44.080 --> 07:48.760 How would you feel if you have to go from the point A to the point B? 07:48.760 --> 07:54.070 But in between these two points, there are many red traffic lights. 07:54.100 --> 07:54.880 Right? 07:55.000 --> 07:56.390 You will feel bad. 07:56.390 --> 08:00.740 And of course it will going to take you more time to go from point A to point B. 08:00.770 --> 08:03.200 The same applies here, right? 08:03.830 --> 08:10.130 If multiple threads of the same process keeps on blocking and unblocking with a very high frequency, 08:10.130 --> 08:16.160 then the threads of the application would span more time in only getting blocked and unblocked rather 08:16.160 --> 08:19.160 than actually executing the application logic. 08:19.160 --> 08:19.970 Right. 08:21.260 --> 08:26.780 More the blocking and unblocking of threads in your application poorer shall be the performance of the 08:26.780 --> 08:28.790 application as simple as that. 08:29.720 --> 08:35.240 So now in the next lecture video we will going to discuss more APIs to work with mutexes and then we 08:35.240 --> 08:39.050 will see how to make use of Mutexes in our actual programs.