Why priority inversion will happen in this case - Linux?

Question

I have read many posts on priority inversion still I am not able to clarify my understanding on some of the parts. I would be happy if someone can throw some light on my question.

Let's describe the situation first. I have a pseudo code, that is self explanatory.

I have a shared resource - int t; Here is the function that will be executed by the three threads - low task p1, medium priority task p2, high priority task p3.

/**Shared resource **/
int t;

/** Function that will be executed by three threads **/

void func()
{
   printf("hello..world");    /** line number 11**/
   mutex_lock(&lock);         /** line number 12**/
   {                          /** line number 13**/
      for(int i = 0; i<=100; i++) /** line number 14**/
      {                          /** line number 15**/
         t++;                   /** line number 16**/
      }                         /** line number 17**/

   }                            /** line number 18**/

   mutex_unlock(&lock);        /** line number 19**/

}                              /** line number 20**/

Let's say p1(low p).. starts executing func(). Now let's say it is in the line number- 13. after mutex lock.Mean while let's say p3 ..starts running. Now, p3 will be blocked because p1 is in the critical section. So, p3 goes to the blocking state.

Scenario- p1 - inside critical section - in the Running State. p3 - blocked state.

Now, let's say p2 starts running. As p2 is in the running state, it will also be blocked by p1 since p2 is in the critical section. Then how come a priority inversion happens here? I am missing the understanding afterwards, kindly please explain me..

Are my understanding below is correct? If not, then please correct it. What should be the situation when the priority inversion happens by p2 task? I understand that priority inversion happens when p2 starts running. After p2 completion, p1 starts running. And p3 never gets a chance.Or it could be that after p2 is done, p3 runs. This makes the p3 delay. In such cases, the mutex timeout can happen.

This was one of the scenario - bug in our software. Where there was a crash due to mutex time out. This was happening because of priority inversion somebody said. This was fixed by setting the mutex attribute to priority inheritance. I was trying to post-mortem the fix, but I am held with the priority inversion fundamentals. I have read many post - Mars path finder, but I am stuck with my questions. Please help me here.

Answer 1

The priority inversion problem does not occur if p2 waits on the mutex as well. In that case, p1 runs until finished, then unlocks the mutex, and the scheduler can schedule p3 next.

Assume p2 is NOT waiting. Instead, it does something completely different, which takes a lot of CPU cycles. While p2 is running, p1 will get little or no CPU resources. So p1 will never (or after a long time) finish and unlock the mutex. When p2 is finally finished, and doesn't use the CPU anymore, p1 will get CPU time again, finish, and unlock the mutex. Now p3 can continue.

In that scenario, p3 had to wait until p2 was finished, even though the priority of p3 was higher than that of p2.

The priority inversion problem is not a problem when all threads are competing for the same resource. It's a problem when there are different resources involved (in my example, the mutex and CPU time), a low priority thread has blocked one resource, a high priority thread is waiting for that resource, but the low priority thread can't free its resource because a medium priority thread prevents the low prio thread from running.

What priority inheritance does is: While p3 is waiting for the mutex, p1 will "inherit" p3's priority. So p1 will get the CPU instead of p2, which means it can finish its task and release the mutex as fast as possible. Once p1 has released the mutex, it will return to its own priority, and the scheduler will allow p3 to run (because p1 is finished and p2's priority is lower than p3's).

Answer 2

To understand this, its better to define the priorities for the tasks, p1,p2 and p3 , priorites will be p1 < p2 < p3.

In normal scenario without priority inversion i.e without any mutex lock when higher priority task wants to run, it justs prempts the lower priority task.

Acquiring mutex will result in disabling the preemption. priority inversion can be explained with just p1 and p3. As in your example, p1 has acquired the lock.

Now p3 being highest priority when tries to acquire the lock, it is blocked.

This is priority inversion where a higher priority task is blocked from running by a lower priority by holding the resource that higher priority task requires.

Refer this for further understanding, What is priority inversion?