lkml.org 
[lkml]   [2004]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.084 / U:1.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site