Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6

[Steven Rostedt <rostedt@goodmis.org>]

On Sat, 2004-12-11 at 11:59 -0500, john cooper wrote:
> Steven Rostedt wrote:
> 
> > [RFC]  Has there been previously any thought of adding priority
> > inheriting wait queues. With the IRQs that run as threads, have hooks in
> > the code that allows a driver or socket layer to attach a thread to a
> > wait queue, and when a RT priority task waits on the queue, a function
> > is call to increase (if needed) the priority of the attached thread. I
> > know that this would take some work, and would make the normal kernel
> > and RT diverge more, but it would really help to solve the problem of a
> > high priority process waiting for an interrupt that can be starved by
> > other high priority processes.
> 
> I think there are two issues here.  One being as above which
> addresses allowing the server thread to compete for CPU time
> at a priority equal to its highest waiting client.  Essentially
> the server needs no inherent priority of its own, rather its
> priority is automatically inherited.  The semantics seem
> straightforward even in the general case of servers themselves
> becoming clients of other servers.
> 

I agree with you on this.

> Another issue is the fact the server thread is effectively
> non-preemptive.  Otherwise a newly arrived waiter of priority
> higher than a client currently being serviced would receive
> immediate attention.  One problem to be solved here is how to
> save/restore client context when a "context switch" is required.

I don't quite understand your point here. 

Say you have process A at prio 20 that waits on a queue with server S. S
becomes prio 20 and starts to run. Then it is preempted by process B at
prio 30 which then comes to wait on the server's queue. Server S becomes
prio 30 and finishes process A's work, then checks the queue again and
finds process B and starts working on process B's work still at prio 30.
The time of process B is still bounded (predictable).

So it's similar to a mutex and priority inheritance. We can look at
process A taking lock L and then when process B blocks on lock L,
process A inherits process B's priority (B being greater prio than A).
The difference is that the work is being done within a mutex as suppose
to a server. The work to keep track of what priorities are being
inherited is even easier than mutexs, since you have a process (the
server) to just point to which process it has inherited, and a wait
queue to store which process needs to be inherited next when the server
wakes up the currently inherited process.

-- Steve