WEBVTT 00:08.030 --> 00:09.270 So welcome back, guys. 00:09.290 --> 00:14.810 Now in this lecture video, we were going to cover the spin lots, so it will take only one lecture 00:14.810 --> 00:18.440 video to cover the spin lots, that is not a very difficult topic to understand. 00:19.310 --> 00:26.270 So when you stop at the traffic red signal and you'll see that it is just five seconds to go green, 00:26.270 --> 00:28.490 you usually don't switch off your car engine, right? 00:29.120 --> 00:32.010 And now I will not ask you, what is the reason behind that? 00:32.010 --> 00:33.470 Do you know it very well? 00:34.130 --> 00:39.410 You are lazy enough to switch off the car in Andrea started up again altogether. 00:40.040 --> 00:40.460 All right. 00:40.460 --> 00:47.000 When you see that it's only five seconds to go green, then why not let your car engine stay on? 00:48.110 --> 00:52.280 So answer to this question forms the foundation of spin lots of spin. 00:52.280 --> 00:56.900 Like, isn't it a structure which is represented by Pietra spin lock type? 00:57.200 --> 00:58.730 So this is the data type. 01:00.850 --> 01:05.270 Just like you have betrayed me, so you have betrayed a spin lactic. 01:06.130 --> 01:06.520 All right. 01:07.300 --> 01:13.180 So now sprint lock works exactly same as normal new taxes, there is no difference. 01:13.690 --> 01:22.420 But the only difference and the major difference is that the the thread went blog by a spin log continues 01:22.420 --> 01:30.760 to spin at the same no operation instruction, whereas in case of normal new taxes, the threat is taken 01:30.760 --> 01:33.830 off the CPU by operating system scheduler. 01:34.450 --> 01:34.840 Right. 01:35.020 --> 01:42.880 And taking the threat off the CPU by the operating system scheduler because the new tax was not available. 01:43.360 --> 01:45.970 That is called forced context switching. 01:46.840 --> 01:49.150 All right, you already know the term context switching. 01:49.570 --> 01:57.160 We have added the word full list because the context switching was triggered because the mere tax was 01:57.160 --> 02:01.060 not available to the threat and therefore the threat got blocked. 02:02.320 --> 02:08.800 So the operating system scheduler decided to take the blocked threat off the CPU and load some other 02:08.800 --> 02:10.390 tried on the CPU instead. 02:11.430 --> 02:16.980 All right, so this leaves to forced contact switching, so you can see in the diagram below, let us 02:17.400 --> 02:20.070 revise the basic concepts of mutex locking. 02:20.640 --> 02:27.810 So let us suppose that the critical section is empty and A31 in the system comes happily and hit the 02:27.810 --> 02:33.600 entry point of the critical section at the entry point of the critical section that the and tries to 02:33.600 --> 02:39.690 lock the available mutants so it logs the attacks here and attractive, unhappily enters a critical 02:39.690 --> 02:41.040 section and execute. 02:42.060 --> 02:42.510 All right. 02:43.110 --> 02:51.360 Now the 382 comes and it again hits the entry point of the critical section, and now it tries to lock 02:51.360 --> 02:52.200 already locked new. 02:53.340 --> 02:59.550 So at this point, the thread T2 got blocked because the mutex is not available now here. 02:59.610 --> 03:09.210 Blocking means that the 32 has been taken all the CPO by the operating system scheduler. 03:09.930 --> 03:16.890 All right, the Sibiu has been snatched away from the 22, and the operating system will see that if 03:16.890 --> 03:21.180 there is any other threat in the system, who can be allotted the CPO? 03:21.960 --> 03:22.380 All right. 03:23.880 --> 03:29.670 And when the threat has done its work in the critical section and then it goes out of the critical section 03:30.090 --> 03:34.560 and at the exit point of the critical section, it unlocks the mutex. 03:36.300 --> 03:45.630 Then only the CPU will load the tragedy to back on the CPU, allocate the mutex to it and then only 03:45.660 --> 03:50.010 the to executes in the critical section. 03:50.730 --> 03:58.040 So you can see that the to first taken of the CPU by the operating system and once the mutex becomes 03:58.050 --> 04:05.970 available, then only 382 is loaded back on the CPU by the operating system scheduler. 04:06.660 --> 04:15.570 All right, so note that the activity of taking the thread off the CPU and then loading the thread again 04:15.570 --> 04:18.090 onto the CPU is an expensive operation. 04:20.010 --> 04:20.400 All right. 04:20.910 --> 04:28.380 The operating system has to do a lot of work in order to pre-empt the CPU from the thread and allocate 04:28.380 --> 04:30.120 a CPU to another trapped. 04:31.020 --> 04:34.440 This is an expensive operation from the operating system point of view. 04:35.790 --> 04:42.170 So now in certain scenarios, we want to avoid the operating system from doing this expensive operation, 04:43.050 --> 04:46.290 and that is why the spin lock has been invented. 04:48.740 --> 04:55.670 Now, let us consider the same example with respect to the spin locks, now the treaty one enters the 04:55.670 --> 05:01.700 A. part of the critical section and it locks the spin lock using improperly tried to spin lock. 05:02.450 --> 05:09.440 So at this point, the lock has been granted to the 21 and the 31 happily executed in the critical section. 05:10.130 --> 05:15.740 So while the treaty one is executing the critical section, let's say 382 comes under the entry point 05:15.740 --> 05:16.820 of the critical section. 05:17.360 --> 05:20.480 There are 22 trials to obtain the lock on. 05:20.480 --> 05:25.310 This has been lock, but this has been lock already granted to the 31. 05:26.000 --> 05:27.170 So 32. 05:28.390 --> 05:34.060 Does not block on the entry point of the critical section, but logically it gets blocked. 05:34.660 --> 05:42.580 Now what I am saying here is that the trade data is made to execute some foolish operations, such as 05:42.580 --> 05:43.150 while one. 05:44.480 --> 05:52.040 That is the 382 is still executing on the CPU, the 32 is still very much alive. 05:52.520 --> 05:59.210 32 is still consuming CPU cycles, but 32 is doing more useful work at all. 05:59.900 --> 06:03.290 It is simply spinning at the no operation instruction. 06:06.610 --> 06:07.030 All right. 06:07.570 --> 06:14.650 The operating system will not take the 382 off the CPU and load some other tried on the CPU, and other 06:14.650 --> 06:17.830 words, the operating system will not trigger any contact switching. 06:18.700 --> 06:25.950 And once the 381 has done its work in the critical section, it will unlock the spin lock using API 06:25.950 --> 06:29.500 arbitrary spin unlock and goes out of the critical section. 06:30.070 --> 06:37.020 So once the log becomes available, the 382 will be granted lock to the spin lock and it will allow 06:37.030 --> 06:38.980 to enter into the critical section. 06:39.670 --> 06:46.780 So now that spin lock is granted to the 382, which is executing in the critical section, so you can 06:46.780 --> 06:52.240 see that in this entire process, the 382 was never taken off the CPU. 06:52.960 --> 06:53.410 All right. 06:53.620 --> 06:58.900 The operating system scheduler never triggered any kind of contact switching. 07:00.640 --> 07:07.600 In order to block the tragedy, too, from entering the critical section, the tragedy was made fool 07:07.870 --> 07:17.170 by making it to execute a no operation instruction in an infinite loop, and the 382 will continue to 07:17.170 --> 07:22.650 do so until the spin log becomes available to the tragedy to. 07:23.680 --> 07:24.130 All right. 07:26.150 --> 07:32.540 So now the question is that what is the benefit we have obtained from doing this and in what scenario 07:32.540 --> 07:36.980 should we use a spin log against the normal commute axis? 07:37.670 --> 07:39.110 So the answer comes here. 07:39.950 --> 07:45.050 We prefer to use a spin lock in the scenarios we are critical section is very insignificant. 07:45.650 --> 07:49.250 That is, you do very less amount of work in the critical section. 07:49.700 --> 07:56.030 For example, you are only setting or reading some kind of a flag in the critical section. 07:56.750 --> 08:03.530 Now sitting or reading a flag is a very tiny operation, and it is not at all computationally intensive. 08:04.340 --> 08:10.220 So if you have critical sections in which the amount of work to be done is very insignificant, then 08:10.220 --> 08:11.870 we use a spin loss. 08:12.320 --> 08:14.090 And the reason is quite simple. 08:14.420 --> 08:20.990 Using a spin lock to protect insignificant critical section, the system gives better performance as 08:20.990 --> 08:22.610 compared to normal access. 08:22.940 --> 08:25.310 And what is the reason for this better performance? 08:25.580 --> 08:30.110 Because your operating system is not busy in triggering the context switching at all? 08:31.070 --> 08:31.520 All right. 08:33.290 --> 08:41.060 So obviously, over use of the spin lock based CPU cycles, you can see that the 382 was running in 08:41.060 --> 08:44.090 an infinite loop at the no operation instruction. 08:44.660 --> 08:50.870 So 32 was intentionally made to waste CPU cycles and it was done intentionally right. 08:50.900 --> 08:54.200 It is not a bug or it is not a drawback of the system. 08:54.200 --> 08:57.950 Our spin locks spin lock has been invented for this purpose. 08:58.940 --> 09:05.210 So we use a spin locks just like normal mutex to safeguard the critical sections, as spin locks can 09:05.210 --> 09:07.620 not be used with condition variables. 09:07.670 --> 09:14.630 So remember that, and now that you are pretty much mature, please read Spin Locks, BS6 APIs yourself 09:14.630 --> 09:15.380 from the thread. 09:15.830 --> 09:22.020 There is no special discussion required to discuss the APIs which makes use of their spin locks. 09:22.040 --> 09:29.570 They are exactly same as the API as we use for normal root access, and while reading about the spin 09:29.570 --> 09:33.710 lock on the internet, do not get confused with the kernel version of a spin locks. 09:34.460 --> 09:34.880 All right. 09:35.210 --> 09:41.690 Here we are talking about spin logs provided by 4:06 APIs, and those spin locks are meant for user 09:41.690 --> 09:42.570 space program. 09:43.220 --> 09:48.350 The kernel has a different version of the spin logs, which are used for thread synchronization in the 09:48.350 --> 09:49.310 kernel space. 09:49.640 --> 09:54.350 So do not start reading about this kernel version of the spin logs on the internet. 09:54.770 --> 10:01.430 They are a little bit more complicated and not easy to understand as compared to the spin logs in the 10:01.430 --> 10:02.210 user space. 10:03.140 --> 10:07.850 All right, so now you can very well answer the questions in what scenarios to use. 10:07.910 --> 10:14.870 Spin logs what is the benefit of using a spin logs or normal mid axis and etc, etc, etc.?