running and blocking states
If a thread in the ready state obtains the CPU and begins executing the thread execution body of the Run method, the thread is running and if the computer has only one CPU, then only one thread is running at any point in time. Of course, there will be multiple threads executing in parallel on a multiprocessor machine, and there will still be multiple threads rotating on the same CPU when the number of threads is greater than the number of processors.
When a thread starts running, it cannot be running all the time (unless its thread execution body is short enough to execute instantaneously), the thread needs to be interrupted while it is running in order to give other threads an opportunity to execute, and the details of the thread scheduling depend on the policies adopted by the underlying platform. For systems with preemptive policies, the system handles tasks for one-hour intervals for each executable thread, and when that time period is exhausted, the system deprives the thread of the resources it occupies and gives other threads an opportunity to execute. When you select the next thread, the system takes into account the priority of the thread.
All modern desktop and server operating systems use preemptive scheduling strategies, but some small devices such as mobile phones may use a collaborative scheduling strategy, in which case only a thread calls its sleep live yield method to discard the resources it occupies. That is, the thread must voluntarily discard the resource it occupies.
The situation in which the thread will enter the blocking state:
1. The thread calls the sleep method to voluntarily discard the processor resources it occupies.
2. The thread invokes a blocking Io method that is blocked before the method returns.
3. The thread is trying to get a sync monitor, but the synchronization monitor is being held by another thread.
4. The thread is waiting for a notification (notify).
5. The program calls the thread's suspend method to suspend the thread. However, this method is easy to cause deadlocks, so you should avoid using this method as much as possible.
After the currently executing thread is blocked, other threads are given the opportunity to execute. When the blocked thread will re-enter the ready state, note that the ready state is not running state. In other words, after the blocking of the blocked thread is lifted, the thread scheduler must wait again to schedule it.
If you need to unblock the above, let the thread re-enter the ready state needs to occur as follows:
1. The thread that called the sleep method passed the specified time.
2. The blocking Io method called by the thread has been returned.
3. The thread successfully obtained the synchronization monitor it was trying to obtain.
4. When a thread is waiting for a notification, another thread sends a notification.
5. A thread that is in a suspended state is called to the resume recovery method.
The thread can only enter the ready state from the blocking state and cannot enter the running state directly. Transitions between ready and running States are usually not controlled, but are determined by system thread scheduling, where the thread is in the running state when the processor resource is acquired by the ready state, and when the running thread loses processing resources, the thread enters the ready state.