Multi-thread (priority inversion)

[Disclaimer: All Rights Reserved. You are welcome to reprint it. Do not use it for commercial purposes. Contact Email: feixiaoxing @ 163.com]

Priority reversal does not happen for developers who write application layers, but it is a problem that the operating system designers cannot escape. Want to know how to handle priority reversal? First, let's see how it happened.

(1) scheduling queue and thread priority

In the operating system, there are many types of threads. For example, the thread status may be suspend, block, ready, or die. We put all the ready threads in a queue, which constitutes a basic scheduling queue.

We also know that we have assigned priority to all threads in order to schedule different time for all threads. For example, the scheduling queue has 32 threads, and each thread has a priority of 1 to 32. What is the significance of these priorities for threads? That is, you can obtain more time slice running opportunities with a higher priority. To put it another extreme, a thread with a priority of 32 can have 32 Basic time slices, so a thread with a priority of 1 can only get the running opportunity of one time slice.

(2) locks and threads

During the queue scheduling process, high-priority threads obtain more running opportunities, but the corresponding low-priority threads have fewer running opportunities. For example, there are now 32 threads with a priority distribution of 1 ~ Between 32. How can these programs run,

Thread 0x20 priority 32 time slices 32

Thread 0x1f priority 31 time slice 31

Thread 0 x 1E priority 30 time slice 30

/* Other threads */

Thread 0x01 priority 01 time slice 01

Therefore, if the total time slice is (1 + 32) * (32/2) = 528, each thread has a chance to run for a period of time. However, the chances of running each thread are different. But it all changes because of the existence of the lock. Assume that the threads 0x20 and 0x1 are fighting for a lock, and the lock is in the running time slice of Thread 0x01, so Thread 0x01 gets the lock. So the Thread 0x20 had to exit the running queue, quietly waiting for the Thread 0x1 to exit the lock.

We have mentioned that low-priority threads have fewer chances to run. Therefore, the Thread 0x01 obtains only 1/528 chance of running. Even if the Thread 0x20 exits the queue, only 1/496, of which 496 = (1 + 31)/2*31. If the Thread 0x01 is still running for a long time, it will be miserable. The thread 0x20 has to wait for a long time to obtain the Thread 0x01 lock. That is, it will only be known in days. At this time, the original priority also loses its meaning, which is the real reason for priority reversal.

(3) Solution
In the past, the purpose of priority setting was to keep some programs running longer and some programs running shorter. However, all this changes from advantages to disadvantages in the face of locks. So what is the solution? In fact, it is not difficult, that is, to increase the priority of Thread 0x01 and let Thread 0x01 exit the lock as soon as possible. The method of switching the priority between thread 0x01 and thread 0x20 is good.

Summary:

(1) priority inversion reminds us that the code segment using the lock should be as short as possible;

(2) Use a small lock instead of a large lock to reduce the chance of conflict;

(3) If the code segment protected by the lock is very short, it is also a good method to directly use the atomic lock.