Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07

Steven Rostedt
2005-03-24T08:31:50Z

Ingo,

I've noticed the following situation which is caused by __up_mutex
assigning an owner right away.

Given 3 processes, with priorities 1, 2, 3, where 3 is highest and 1 is
lowest, and call them process A, B, C respectively.

1. Process A runs and grabs Lock L.
2. Process B preempts A, tries to grab Lock L.
3. Process A inherits process B's priority and starts to run.
4. Process C preempts A, tries to grab Lock L.
5. Process A inherits process C's priority and starts to run.
6. Process A releases Lock L loses its priority.
7. Process C gets Lock L.
8. Process C runs and releases Lock L.
9. With __up_mutex, Process B automatically gets Lock L.
10. Process C tries to grab Lock L again, but is now blocked by B.

So we have a needless latency for Procss C, since it should be able to get
lock L again. The problem arises because process B grabbed the lock
without actually running.

Since I agree with the rule that a lock can't have waiters while not being
owned, I believe that this problem can be solved by adding a flag that
states that the lock is "partially owned". That is the ownership of the
lock should be transferred at step 9, but a flag is set that it has not
been grabbed. This flag would be cleared when Process B wakes up and
leaves the __down call.

This way when process C tries to get the lock again, it sees that it's
owned, but B hasn't executed yet. So it would be safe for C to take the
lock back from B, that is if C is greater priority than B, otherwise it
would act the same.

If you agree with this approach, I would be willing to write a patch for
you.

-- Steve