Transferred from: http://www.cnblogs.com/wz19860913/archive/2008/08/04/1259807.html
Each thread has a priority, the range is 0~31,0 to the lowest priority, and 31 is the highest priority. When the system decides which thread needs to be dispatched, first check if there is a scheduled thread with a priority of 31, and if so, choose one to schedule it. When the thread's time slice arrives, the system checks to see if there is another scheduled thread with a priority of 31, and dispatches it if it exists.
As long as there is a single thread with a scheduled priority of 31, the system will never dispatch a thread with a priority of 0~30, which will cause other threads to "starve".
High-priority threads tend to "break down" the execution of low-priority threads. For example, when a thread with a priority of 15 is running, and if the system finds a thread with a priority higher than 15 to dispatch, the high-priority thread "interrupts" the execution of that low-priority thread, even if the lower-priority time slice is halfway through.
In addition, when the system boots, the system creates a special thread called the "Zero page" (0 page) thread, which is the only thread in the system that has a priority of 0 (lowest). When no thread in the system needs to be executed, the thread is responsible for clearing 0 of all RAM pages in the system (that is, resource recycling).
Thread precedence has an abstraction layer concept.
For some historical reasons, Microsoft has not completely fixed the behavior of the thread scheduler. Microsoft did not allow the application to take full advantage of the scheduler's features. Microsoft claims that the behavior of the scheduler is a change and needs attention when programming.
By these points, your application can have its own scheduling characteristics.
The Windows API fully reflects an abstraction layer of system scheduling. In this way, it is not possible to communicate directly with the scheduler of the system, instead, you can call the API function to convert these parameters according to the different versions of the system. This layer is the abstraction layer of thread precedence.
Here's a detailed description of what this abstraction layer is all about:
for a process , Windows has a "priority class" concept. These priority classes function with all threads in the process. Windows 2000/xp/2003/vista supports 6 "Priority classes":
1, real-time: real-time
2, High: Tall
3, Above Normal: higher than the standard
4. Normal: Standard
5, Below Normal: Below the standard
6, Idle: free.
A process should avoid using the "real-time" priority class, because using that priority class can cause threads in other processes to be difficult to schedule, or even to interrupt or preempt the execution of the system thread. The "high" priority class should also be avoided unless there is a special need to work with this priority level.
When a process's "priority class" is determined, it is only necessary to consider the priority relationships among the threads within the process.
for threads in a process , there is a " relative Thread priority" concept, which can determine the priority relationship between multiple threads in a process.
Windows supports 7 "relative thread priorities":
1, Time-critical: Critical time (highest relative thread priority)
2, Heightest: Highest (translation is so translated, but not the highest relative thread priority)
3, Above Normal: higher than the standard
4. Normal: Standard
5, Below Normal: Below the standard
6, Lowest: Minimum (translation is so translated, but not the lowest relative thread priority)
7. Idle: Free
There is no mention of any of the priorities of 0~31. Developers never have to set the priority of a thread, that is, no need to set a thread priority to one of 0~31. The operating system is responsible for mapping "priority classes" and "relative thread priorities" to a specific priority. This mapping is different depending on the version of Windows.
The following is the thread priority mapping for Windows 2000/xp/2003/vista (the book is only Vista, but compared to the fourth edition of this book, 2000 and Vista are the same):
line threads to priority |
Process priority class |
idle |
below Normal |
normal |
above Normal |
high |
real-time |
Time-critical |
15 |
15 |
15 |
15 |
15 |
31 |
Highest |
6 |
8 |
10 |
12 |
15 |
26 |
Above Normal |
5 |
7 |
9 |
11 |
14 |
25 |
Normal |
4 |
6 |
8 |
10 |
13 |
24 |
Below Normal |
3 |
5 |
7 |
9 |
12 |
23 |
Lowest |
2 |
4 |
6 |
8 |
11 |
22 |
Idle |
1 |
1 |
1 |
1 |
1 |
16 |
Look closely at the table and now know why it's best not to set the process priority class to live, because a process with a "real time" priority class Then all threads in the process have a higher priority (at least 16) than any other thread in the process with other priority classes (up to 15). This causes threads in the process with other priority classes less than "live" to be dispatched.
It is important to note that the "priority class" is an abstract concept that is for a process, but not that the process can be scheduled, only that the thread can be dispatched. Microsoft is proposing this concept only to help you differentiate it from the internal operation of the scheduler. A "priority class" should be a priority that can affect all threads in a process.
The above describes the thread priority content, including the thread's "specific priority", "priority abstraction Layer" content (process "priority class", "line threads to priority", etc.).
Here's how to set the priority of a thread in programming:
A process, often associated with a "priority class", you can set the specific contents of this priority class in the Fdwcreate parameter of the CreateProcess function, there are 6 options for 6 priority classes:
1, Realtime_priority_class:real-time, real-time priority class
2, High_priority_class:high, high-priority class
3, Above_normal_priority_class:above Normal, higher than the standard
4, Normal_priority_class:normal, standard
5, Below_normal_priority_class:below Normal: Below the standard
6, Idle_priority_class:idle, idle
You can also change a particular process priority class by calling the setpriorityclass function to get there.
BOOL setpriorityclass ( HANDLE hprocess, // process handle specified by DWORD fdwpriority); // priority class (corresponding to the above 6 types of values)
For example, the following code sets the priority class for the current process to idle:
Setprioriytclass (GetCurrentProcess (), idle_priority_class);
Of course, you can get a priority class for a process by calling the Getpriorityclass function:
DWORD Getpriorityclass (HANDLE hprocess);
The value returned by the function is one of the values of the corresponding 6 priority classes.
When a thread is created, its "line threads to priority" defaults to normal (standard). The CreateThread function does not provide the ability to set the priority of line threads. You can call the SetThreadPriority function to set the relative priority of a thread.
BOOL setthreadpriority ( HANDLE hthread, // thread handle specified int npriority); // Line Threads Priority (value corresponds to the following)
This function takes a thread handle and line threads to the priority value, setting the relative priority of the corresponding thread. The line threads the priority value as follows:
1, Thread_priority_time_critical:time-critical, key time (highest)
2, Thread_priority_highest:highest, highest (in fact, "sub-high")
3, Thread_priority_above_normal:above Normal, higher than the standard
4, Thread_priority_normal:normal, standard
5, Thread_priority_below_normal:below Normal, below the standard
6, Thread_priority_lowest:lowest, the lowest (in fact, "sub-low")
7, Thread_priority_idle:idle, Idle (minimum)
You can call the Gettreadpriotiry function to get the relative priority of a particular thread.
int GetThreadPriority (HANDLE hthread); // function returns the above 7 values
In order to create a line threads the priority is not a standard thread, for example to create a higher-than-standard thread, you can pass the create_suspended parameter to CreateThread, creating a thread with a starting state of "suspended". Then call the SetThreadPriority function to set the relative priority of the thread, and then call the ResumeThread function to resume the thread's run. The code is as follows:
0, ThreadFunc, NULL, create_suspended, &dwThreadID); SetThreadPriority (Hthread, thread_priority_above_normal); ResumeThread (Hthread); CloseHandle (hthread);
The operating system dynamically increases the thread's base priority level (0~31), typically in response to some I/O events.
In some cases, it can be inconvenient to dynamically increase thread priority. You can call the Setprocesspriorityboost and SetThreadPriorityBoost functions to tell the system whether it needs to dynamically increase the thread priority.
bool Setprocesspriorityboost (HANDLE hprocess, bool bdisablepriorityboost); BOOL SetThreadPriorityBoost (HANDLE hthread, bool bdisablepriorityboost);
The second parameter of these two functions is used to inform the system whether to dynamically increase the priority class of the specified process and the relative priority of the specified thread.
You can also get this information using the following two functions:
BOOL Getprocesspriorityboost (HANDLE hprocess, Pbool pbdisablepriorityboost); BOOL Getthreadpriorityboost (HANDLE hthread, Pbool pbdisablepriorityboost);
"Windows via C + +" Learning notes-thread priority "Go"