Thread.Sleep (0) meaning & multithreading

We may often use the Thread.Sleep function to suspend a thread for a period of time. So do you have a proper understanding of the use of this function? Consider the following two questions:

Assuming it's 2008-4-7 12:00:00.000, if I call Thread.Sleep (1000), will this thread wake up in 2008-4-7 12:00:01.000?

Someone's code is a seemingly puzzling word: thread.sleep (0). Since it's Sleep 0 milliseconds, what's the difference between him and the code?

Let's review the operating system principles first.

There are a number of strategies for CPU contention in the operating system. UNIX systems use a time-slice algorithm, while Windows is preemptive.

In the time slice algorithm, all the processes are queued. The operating system assigns a period of time to each process in their order, that is, the time that the process is allowed to run. If the process is still running at the end of the time slice, the CPU is stripped and assigned to another process. If the process blocks or ends before the end of the time slice, the CPU switches immediately. What the scheduler has to do is maintain a list of ready processes, which is moved to the end of the queue when the process runs out of its time slice.

The so-called preemptive OS, which means that if a process gets CPU time, it will completely occupy the CPU unless it itself abandons the CPU. So it can be seen that in the preemptive operating system, the operating system assumes that all processes are "good personality", will actively quit the CPU.

In a preemptive operating system, assume that there are several processes in which the operating system calculates a total priority based on their priority, the time of starvation (the CPU has not been used for a long time). The operating system will give the CPU the highest priority for this process. When the process finishes executing or when it is actively suspended, the operating system recalculates the total priority of all processes and then takes the CPU control to him with the highest priority.

We use the split-cake scenario to describe the two algorithms. Suppose there is a steady stream of cakes (a steady stream of time), a pair of knives and forks (a CPU), and 10 people waiting to eat the cake (10 processes).

If the UNIX operating system is responsible for splitting the cake, then he will rule: everyone up to eat 1 minutes, time to replace one. The last person finishes eating and starts from scratch. So, regardless of whether the 10 people have different priorities, different levels of hunger and different appetites, everyone can eat for 1 minutes when they come up. Of course, if someone is not very hungry, or eat small, after eating for 30 seconds after eating full, then he can talk to the operating system: I have eaten (hang). So the operating system will let the next person go on.

If the Windows operating system is responsible for splitting the cake, then the scene is very interesting. He will rule: I will calculate a priority for each of you based on your priorities and hunger level. The person with the highest priority can come up to eat the cake-until you don't want to eat it. When this guy is finished, I'll prioritize the priorities, the hunger level, and then give the highest priority to the person.

In this case, the scene is interesting-maybe some people are ppmm and therefore have high priority, so she can often come to eat cakes. Maybe another person is an ugly man, and go very WS, so the priority is particularly low, so long time to his turn (because with the passage of time, he will become more and more hungry, so the overall priority will be more and more high, so one day will be his turn). Moreover, if accidentally let a big fat man get a knife and fork, because he appetite big, maybe he will occupy the cake for a long time to eat continuously, causing the person next to swallow saliva there ...

Also, this could happen: the operating system now calculates the result that the 5th PPMM has the highest total priority and is taller than the others. So call number 5th to eat the cake. Number 5th ate for a little while, felt less hungry, and said, "I'm not eating" (hang). As a result, the operating system recalculates the priority of everyone. Since number 5th had just been eaten, her hunger became smaller, so her total priority became smaller, and the rest of the people became more hungry because they waited a little longer, so the overall priority was also bigger. But it's still possible that number 5th has a higher priority than anything else, but it's only a little bit higher now-but she's still the top priority. So the operating system will say: number 5th mm up to eat cake ... (No. 5th mm Heart depressed, this has not just eaten ... People want to lose weight ... Who told you to look so beautiful and get that high priority?

So what does the Thread.Sleep function do? Also use the scene of the cake just now to describe. In the above scene, 5th mm after eating a cake, feel already have 8 cent full, she felt in the next half an hour will not want to eat cake again, then she will talk with the operating system said: In the next half an hour don't call me up to eat cake. In this way, when the operating system recalculates the total priority of everyone in the next half hour, it ignores number 5th mm. The sleep function is doing this, and he tells the operating system "I'm not going to compete for CPU in the next few milliseconds."

After reading the role of Thread.Sleep, let's think about two issues at the beginning of the article.

For the first question, the answer is: not necessarily. Because you're just telling the operating system: I don't want to compete in the CPU for the next 1000 milliseconds. Then 1000 milliseconds after that, maybe another thread is using the CPU at this time, then the operating system will not reallocate the CPU until the thread hangs or ends, and even if it happens to be the operating system CPU allocation, Then when the front-line is not necessarily the highest priority, the CPU may be preempted by other threads.

As such, the thread has a resume function that is used to wake the suspended thread. As mentioned above, this function simply "tells the operating system that I am participating in the CPU competition from now on", this function's call does not immediately make the thread gain CPU control.

For the second question, the answer is: Yes, and the difference is obvious. Suppose we just had another PPMM 7th in the cake scene, and her priority was very high (because it was very beautiful), so the operating system would always call her to eat the cake. Moreover, number 7th also likes to eat cakes very much, and appetite is also very big. However, the number 7th character is very good, she is very kind, she did not eat a few mouth will think: if there is someone else than I need to eat cake, then I give him. So she can say to the operating system every few mouths: let's recalculate the overall priority for everyone. However, the operating system does not accept this recommendation-because the operating system does not provide this interface. So the number 7th mm changed the saying: "In the next 0 milliseconds don't call me up to eat cake." This command operating system is accepted, so at this time the operating system will recalculate the overall priority of everyone-note that this time is calculated with the number 7th, because "0 milliseconds has passed". So if there are no more cake-eating people than number 7th, then the next 7th will be called up to eat cake.

Therefore, Thread.Sleep (0) is the role of "triggering the operating system to immediately restart the CPU competition." The result of the competition may be that the current thread still gains control of the CPU and may be replaced by another thread to gain control of the CPU. This is also what we often write in cycle Thread.Sleep (0), because this gives other threads such as the paint thread the power to gain control of the CPU, so that the interface will not feign death there.

In addition, although it is mentioned above that "unless it itself abandons the CPU, it will completely occupy the CPU", but this behavior is still constrained-the operating system will monitor the situation you occupy the CPU, if a thread is found to occupy the CPU for a long time, will force the thread to suspend, so in fact does not appear " A thread has been hogging the CPU for "the situation." As for our cycle caused the program to feign death, not because the thread has been hogging the CPU. In fact, during this time the operating system has been a number of CPU competition, but other threads in a short period of time after the CPU control to quit, and then it is the thread to continue to execute the loop, so it took a long time to be forced to suspend the operating system ... So reacting to the interface, it looks as if the thread has been hogging the CPU.

Finally, the text line, the process is a bit confusing, in fact, in the Windows principle level, CPU competition is thread-level, this article in the process, the thread as the same thing as well.

Thread.Sleep (0) meaning & multithreading