[Autogenerated] let's now take a look at simple thread scheduling.
In general thread scheduling is a very complex thing because
you have to contend with several aspects,
some of them conflicting.
For example, you might have multiple processors of course,
you also might have hyper threading active on processors.
So when you have a thread ready,
should you give it to another logical processor of the
same core or maybe a different core?
And if you have two logical processors as a very simple example,
one of them is running some thread and then you have
another threat that wants to execute code.
Should you wake up the other processor in order to
give that thread CPU to run on?
Perhaps it's better to wait a little bit until the
first thread will go into a wave state,
which would allow the first processor which is already ready to
go and and running to be used for the second threat because you
might want to save on energy.
So these things are sometimes conflicting in general.
It is a very complex problem,
but we can start small with the case we have a single processor on the system.
Obviously systems today have more than one processor,
but even with the one processor case,
the foundations of the fundamentals of scheduling are the same.
Of course there are some tweaks and some extra complexity.
We have multiple processors, some of which I'll describe later on.
So here's what happens in this particular example.
We have a single CPU and we have seven threats that are in the ready state.
Remember that the ready state means that the threat wants to run.
It wants to execute code on the other hand,
there might be hundreds of thousands of threats which are
in the waiting state somewhere here,
which is very typical in on a Windows system that don't want to run right now.
So the kernel scheduler doesn't care about those threats at this point in time.
So now we have several threats that do want to run.
And unfortunately there's only one processor,
which means that only one thread can be in the running state at a time.
So what does the schedule do?
The first thing it does is arrange the threats in
descending levels of priorities.
So they're sorted.
We have threads one and two.
He priority 31 thread number three with priority 16
threads 45 and six in priority eight.
And thread seven priority for.
So the first thing it does it says, OK,
who's the thread with the highest priority?
There are two of those threats.
One and two.
Let's just grab the first one in the list,
let's say that threat number one and it becomes the ready.
Sorry, the running thread,
it's currently executing code on the processor for how long it's going
to get something called the time slides or quantum,
which we discuss very soon in the next slides but let's
just assume for discussion purposes this is 30
milliseconds or roughly 30 milliseconds.
So now the threat runs for 30 milliseconds.
And assuming it has lots of work to do, it's not done,
then the colonel will forcefully perform a context switch,
removing threat number one from the processor,
bring it back to the ready state because it's not done doing its thing and
putting threat number two in its place because threat number two has the
same priority so it's entitled to have the same kind of power over
processors so it gets its own Quantum, its own Let's assume 30 milliseconds.
What happens next assuming threat to has still lots of work to do another
context which occurs and thread one becomes the running thread,
whereas threat to goes back into the ready state.
So the basic rule is priority matters.
The higher the priority is the more likelihood for threat to
run and essentially for this kind of system.
If threats one and to want to run all the time,
all the other threats will starve and will never get any CPU time.
This is just the way it is.
That's just the reality of priorities.
It's not fair perhaps, but hey, priorities are unfair by definition,
fortunately threats don't want forever.
Typically threats do something and then they're going to away state,
waiting for something to occur.
Maybe performing an eye operation, waiting for the operation to complete.
Maybe waiting on some kernel object to become signaled.
Maybe waiting on the window messages handling some kind of user interface.
Whatever the reason might be, let's assume for demonstration purposes,
the threads one and to go into the waiting state,
joining the other thousands of threads that are there waiting as well.
So now the next threat in line that has the highest
priority threat number three with property 16.
So it becomes the running thread, it gets its own Quantum,
assuming it still has stuff to do.
It's going to get another Quantum, because it's the only one in its level.
So this thread is currently the king of the system,
so to speak,
so it can continue to run for as long as it likes unless something changes.
For example, suppose threat number one gets whatever it was waiting for.
When that happens,
threat number one goes into the ready state and
immediately to the running state.
Preempting threat number three,
which go goes back to the ready state in case that it still has work to do.
So again,
this demonstrates the fact that priority matters when
number one has a higher priority.
So it preempts the lower priority threat,
which in this case is threat number three.
And so let's assume that threat number 12 and three
all go into the waiting state.
They have nothing to do at this point, they're waiting for something.
So at this point, threats 45 and six are the highest in priority.
So that each would get their own Quantum assuming they have lots of
work to do and because they're considered the same,
they have all the same priority.
They're going to run robbing each one, getting its own Quantum.
So that's the basic ideas of scheduling and for a single CPU system,
that is exactly how scheduling works.
There's really nothing else here because obviously there's just one
processor power management is out of the picture.
So this is exactly how scheduling worked and still works on a single CPU system.
If you can get that kind of system in hand.
Now obviously there are some challenges here.
For example,
threat number seven here with priority of four might not get a
lot of CPU time because there's lots of activity with high
higher priority threats on the one hand,
it's just the way it is, it's life.
It's unfair because of priorities and priorities should be probably used
because some threats are more important the other than others.
However,
we still might want to give three number seven some chance to run a little bit
from time to time to make some kind of forward progress.
So, this is one of the reasons a boost might occur in this particular case.
This is because of a starvation scenario.
If threat number seven here,
that is not able to run for at least roughly four seconds,
it's going to get its priority boosted to level 15 And will get a single
quantum running at that level because probably 15,
it has a much higher chance of getting CPU time once it gets it,
it can run for at most one quantum in that level and then the priority
will drop back immediately to the regional priority.
In this case, priority for so at least every four or so seconds.
The threat will be able to make forward progress almost systems of course,
if threats are running probably 16 Higher,
that will not work.
And we know that changes in priority or priority boost only occur
for priorities up to 15 in the normal range,
but that's definitely better than nothing.
So there are some tweaks that are being done,
some of them controlled by the colonel,
some of them controllable by device drivers by the way to make the
system a bit more fair to some or in some respect.
But still priority is the main the main mechanism that is used to select
or to choose the next threat to execute on the system.
And for a single CPU system this is fairly straightforward as demonstrated here.