So welcome back, guys.
Now in this lecture video, we were going to cover the spin lots, so it will take only one lecture
video to cover the spin lots, that is not a very difficult topic to understand.
So when you stop at the traffic red signal and you'll see that it is just five seconds to go green,
you usually don't switch off your car engine, right?
And now I will not ask you, what is the reason behind that?
Do you know it very well?
You are lazy enough to switch off the car in Andrea started up again altogether.
All right.
When you see that it's only five seconds to go green, then why not let your car engine stay on?
So answer to this question forms the foundation of spin lots of spin.
Like, isn't it a structure which is represented by Pietra spin lock type?
So this is the data type.
Just like you have betrayed me, so you have betrayed a spin lactic.
All right.
So now sprint lock works exactly same as normal new taxes, there is no difference.
But the only difference and the major difference is that the the thread went blog by a spin log continues
to spin at the same no operation instruction, whereas in case of normal new taxes, the threat is taken
off the CPU by operating system scheduler.
Right.
And taking the threat off the CPU by the operating system scheduler because the new tax was not available.
That is called forced context switching.
All right, you already know the term context switching.
We have added the word full list because the context switching was triggered because the mere tax was
not available to the threat and therefore the threat got blocked.
So the operating system scheduler decided to take the blocked threat off the CPU and load some other
tried on the CPU instead.
All right, so this leaves to forced contact switching, so you can see in the diagram below, let us
revise the basic concepts of mutex locking.
So let us suppose that the critical section is empty and A31 in the system comes happily and hit the
entry point of the critical section at the entry point of the critical section that the and tries to
lock the available mutants so it logs the attacks here and attractive, unhappily enters a critical
section and execute.
All right.
Now the 382 comes and it again hits the entry point of the critical section, and now it tries to lock
already locked new.
So at this point, the thread T2 got blocked because the mutex is not available now here.
Blocking means that the 32 has been taken all the CPO by the operating system scheduler.
All right, the Sibiu has been snatched away from the 22, and the operating system will see that if
there is any other threat in the system, who can be allotted the CPO?
All right.
And when the threat has done its work in the critical section and then it goes out of the critical section
and at the exit point of the critical section, it unlocks the mutex.
Then only the CPU will load the tragedy to back on the CPU, allocate the mutex to it and then only
the to executes in the critical section.
So you can see that the to first taken of the CPU by the operating system and once the mutex becomes
available, then only 382 is loaded back on the CPU by the operating system scheduler.
All right, so note that the activity of taking the thread off the CPU and then loading the thread again
onto the CPU is an expensive operation.
All right.
The operating system has to do a lot of work in order to pre-empt the CPU from the thread and allocate
a CPU to another trapped.
This is an expensive operation from the operating system point of view.
So now in certain scenarios, we want to avoid the operating system from doing this expensive operation,
and that is why the spin lock has been invented.
Now, let us consider the same example with respect to the spin locks, now the treaty one enters the
A. part of the critical section and it locks the spin lock using improperly tried to spin lock.
So at this point, the lock has been granted to the 21 and the 31 happily executed in the critical section.
So while the treaty one is executing the critical section, let's say 382 comes under the entry point
of the critical section.
There are 22 trials to obtain the lock on.
This has been lock, but this has been lock already granted to the 31.
So 32.
Does not block on the entry point of the critical section, but logically it gets blocked.
Now what I am saying here is that the trade data is made to execute some foolish operations, such as
while one.
That is the 382 is still executing on the CPU, the 32 is still very much alive.
32 is still consuming CPU cycles, but 32 is doing more useful work at all.
It is simply spinning at the no operation instruction.
All right.
The operating system will not take the 382 off the CPU and load some other tried on the CPU, and other
words, the operating system will not trigger any contact switching.
And once the 381 has done its work in the critical section, it will unlock the spin lock using API
arbitrary spin unlock and goes out of the critical section.
So once the log becomes available, the 382 will be granted lock to the spin lock and it will allow
to enter into the critical section.
So now that spin lock is granted to the 382, which is executing in the critical section, so you can
see that in this entire process, the 382 was never taken off the CPU.
All right.
The operating system scheduler never triggered any kind of contact switching.
In order to block the tragedy, too, from entering the critical section, the tragedy was made fool
by making it to execute a no operation instruction in an infinite loop, and the 382 will continue to
do so until the spin log becomes available to the tragedy to.
All right.
So now the question is that what is the benefit we have obtained from doing this and in what scenario
should we use a spin log against the normal commute axis?
So the answer comes here.
We prefer to use a spin lock in the scenarios we are critical section is very insignificant.
That is, you do very less amount of work in the critical section.
For example, you are only setting or reading some kind of a flag in the critical section.
Now sitting or reading a flag is a very tiny operation, and it is not at all computationally intensive.
So if you have critical sections in which the amount of work to be done is very insignificant, then
we use a spin loss.
And the reason is quite simple.
Using a spin lock to protect insignificant critical section, the system gives better performance as
compared to normal access.
And what is the reason for this better performance?
Because your operating system is not busy in triggering the context switching at all?
All right.
So obviously, over use of the spin lock based CPU cycles, you can see that the 382 was running in
an infinite loop at the no operation instruction.
So 32 was intentionally made to waste CPU cycles and it was done intentionally right.
It is not a bug or it is not a drawback of the system.
Our spin locks spin lock has been invented for this purpose.
So we use a spin locks just like normal mutex to safeguard the critical sections, as spin locks can
not be used with condition variables.
So remember that, and now that you are pretty much mature, please read Spin Locks, BS6 APIs yourself
from the thread.
There is no special discussion required to discuss the APIs which makes use of their spin locks.
They are exactly same as the API as we use for normal root access, and while reading about the spin
lock on the internet, do not get confused with the kernel version of a spin locks.
All right.
Here we are talking about spin logs provided by 4:06 APIs, and those spin locks are meant for user
space program.
The kernel has a different version of the spin logs, which are used for thread synchronization in the
kernel space.
So do not start reading about this kernel version of the spin logs on the internet.
They are a little bit more complicated and not easy to understand as compared to the spin logs in the
user space.
All right, so now you can very well answer the questions in what scenarios to use.
Spin logs what is the benefit of using a spin logs or normal mid axis and etc, etc, etc.?