[Autogenerated] to get a more rounded view of threads,
let's look at all the states that the threat can be in.
We know that there are three main states ready running and
waiting but there's some other states.
That might be interesting to look at.
So let's start with the first state which is called the in its state.
This is the state where that the threat is at,
when the threat is just being created, being initialized,
it stack has been created and so on.
It can't really do anything at this point.
And then assuming the threat is not created in a suspended state,
then it goes into the ready state.
The ready state says, hey I want to run code now,
I would like to get a processor as soon as possible.
This is where the schedule notices the threat technically behind the scenes,
there are actually two states called the ready and deferred ready,
they mean exactly the same thing but there are two states used in
order to kind of limit the some of the contention looking that is
happening in the thread database there but it's not really
important for understanding purposes.
I'm grouping these two states in the same state so once the threat is
eligible to run it's going to be in the standby state which means going to be
the next thread that is eligible to run and it's kind of getting ready to get
a processor so it's the next one in line,
so to speak.
However, if a thread with a higher priority becomes ready,
then it might go back to the ready state.
If this is joe what happens however once the processor becomes
available it's going to move into the running state where it can
actually execute code on a processor.
What could happen from this particular state?
One option is that the threat will simply be done,
it's done with its work,
it's going to go into a terminate state which of
course from there we can't go anywhere.
Technically it's possible to get to the state from any other state.
If someone calls a termination API such as terminate threat and that
might cause the threat to go to terminate state immediately but I'm not
showing that in the diagram to make diagram more easily understandable
and this is a fairly uncommon case.
The other option is a pre emption.
Maybe the quantum has ended and another threat with the same
priority is also ready and supposed to be running.
Or maybe the preemption happens because the higher priority thread became
ready and removed that current threat from the processor.
Whatever reason happened here the threat goes back into the ready state,
it still wants to run and hopefully it will get another CPU maybe the same one.
Maybe a different one sometime later and other options that
the threat doesn't want to run anymore.
It wants to wait for something to occur such as performing an eye
operation waiting for that operation to to finish.
So at that point the threat has nothing to do.
It doesn't need any processor It goes into a wait state so
that other threads or another threat can use that same
processor from the waiting state.
The most common thing to occur is going back to the ready state when
whatever the threat was waiting for has finally arrived.
And so it says, hey,
mr scheduler Please take me into consideration and I want to run again.
Hopefully we'll get to the running state as soon as possible.
However, there is another state that the threat might go into temporarily.
A very short lived state called transition and transition
state happens in the following case.
As we see in the next module,
every thread has a kernel stack and the current stack is normally in RAM.
I'll explain the next model, why that is in important.
However, when a threat is in a wait state for a long time,
especially if the entire process, it's part of If all the threats,
they are in a waiting state for a long time,
the kernel stacks of these threats might be paged out by the colonel to have
more RAM available for other processes that really need it.
However, when that process,
suddenly some threats there need to start actually executing code,
then these threats have to go into the registered but you
are not allowed to be in the reddest state unless the
kernel stack is in physical memory.
So the transition state represents that in swap where the kernel stack
is read from the page file back into physical memory,
and only then the threat is really ready to run code and
again and explain the importance of the kernel stag being
in RAM in the next module.
So this is the entire state machine of threats.
You might be wondering what are these numbers shown in parenthesis?
So the numbers in parenthesis are the internal state numbers,
as are being managed by the kernel,
and we'll be able to use certain tools to see those state numbers to
figure out what the threat is doing right now,
which state the threat is at any given point in time,
which we'll see in the next demonstration.