Messages in this thread | | | Date | Mon, 13 Dec 2004 18:45:57 -0500 | From | john cooper <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 |
| |
Steven Rostedt wrote:
>>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).
My point was the server thread in the above scenario is non-preemptable. Otherwise upon B soliciting service from S, A's work by S would be preempted and attention would be given immediately to B.
This may very well be a concession to simplicity in the design. The server context on behalf of client A would need to be saved [somewhere] when B caused the preemption and restored when A's priority deemed doing so.
For a mutex, the priority promotion of 'anything of lower priority in my way' to logical completion is needed to preserve the semantics of a mutex, ie: mutex ownership cannot be preempted. However in general this doesn't hold for the server thread model. We could redirect the server immediately to a different client at the cost of additional context switching -- a compromise to consider.
Again this is the general case. It is likely for critical sections to exist in the server thread where preemption must be disabled analogous to the kernel/cpu preemption model.
> ...The work to keep track of what priorities are being > inherited is even easier than mutexs...
The dependency chain does exist here as for mutexes if we allow servers to wait on other servers. Note in this usage a preemptive server model favors preemption over priority propagation unless the target server is itself blocked.
Note here it is more obvious [at least to me] circular dependencies are to be disallowed. With mutexes, especially of the reader/writer variety, circular ownership dependencies can go unnoticed which will confound the priority promotion logic.
-john
-- john.cooper@timesys.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |