Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!purdue!haven!uflorida!travis!hrshcx!steved From: steved@hrshcx.csd.harris.com (Steve Daukas) Newsgroups: comp.realtime Subject: Re: Real-Time UNIX: guaranteed context switch times Vs interrupts Message-ID: <993@hrshcx.csd.harris.com> Date: 19 Feb 91 15:05:52 GMT References: <9102181527.AA02102@ucbvax.Berkeley.EDU> Organization: Harris Computer Systems - Fort Lauderdale, Fl. Lines: 96 In article <9102181527.AA02102@ucbvax.Berkeley.EDU>, jordan@winvmd.iinus1.ibm.com writes: > Novice question: I've read items in the press which state that LynxOS > guarantees a maximum user process context switch time. Steve Daukas of > Harris implies on a previous posting that CX/RT can do the same. Can > anyone explain (without giving away trade secrets) how a UNIX-based > real-time O/S can guarantee context switch time in the presence of > interrupts? Surely interrupts take priority over all user processes? And > a stream of interrupts could potentially delay a context switch > indefinitely. Before I start, let me say that Harris guarantees context switch times for both CX/UX and CX/RT on Harris' hardware. I'd bet that LynxOS' guaranteed times are different depending on what hardware its running on... (just an observation - I've never seen lynxOS before, only heard of it from our customers who use to use it). Further, the number we guarantee is based on over 30 man-years of effort re-writing the guts of the Kernal as described below... Keep in mind its SVID, SVVS, and POSIX 1003.x compliant (as well as 88open BCS for the 88K systems). > Also, do these systems allow users to add new interrupt > handlers? If so, are there disclaimers regarding the context switch > time, given that the path length of a user-added interrupt handler is > unknown? I think you first must do away with the notion of Unix per say. Unix, the AT&T or BSD standard kernals, are _not_ real-time and cannot guarantee anything. What you need to do in order to guarantee deterministic behavior is: 1) allow for preemtive processing; 2) multithread the kernal; and 3) do away with the "normal" Unix scheduler (fairness) and replace it with something that doesn't screw with priorities. If the Kernal is preemtive, then a higher priority process can get in and do what it needs without a dead-lock or deadly-embrace. If the Kernal is multithreaded, then more than one process can be in the Kernal at the same time, even in the same service. This can be accomplished with spin-locks, major and minor number protection, etc.. One can even add their own Device Driver and, providing its multithreaded, not violate the determinism (e.g., spl8 doesn't do what you would expect in this kind of Kernal). If the Kernal's context switcher doesn't try to be fair based on time quantums et. al., then you don't have to worry about a process executing at time X one iteration and at time X+delta the next iteration. Static priorities alone or in conunction with non-static priorities can achieve a deterministic system. Interrupt handlers are just another process and can be handled according to the same model (I'm leaving alot out here). In a multiprocessor environment, the interrupts must be vectorable to a given CPU where the handler can then process it. This requires not only 1 - 3 above, but also a symmetric Kernal as well. The symmetric kernal requires no master slave relationship, and therefore an interrupt handler will use the system service(s) it needs irregardless of what other processes are in the Kernal from other CPUs. Further, even if the ISR is in the same service as another process, both can execute on their respective CPUs _in_parallel_ until a spin-lock. There the higer priority process will preempt the lower... This self-same structure works on a single CPU as well (spin-locks protect such things as Kernal data structures...). Now, if the interrupts are posted every 100 usec, for example, you need the ability to respond to and process each. The Kernal must allow for the response and processing in the most efficacious way. The hardware must provide the horsepower. The interrupt hardware must be fast (e.g., less than 4 or 5 usec) so that the CPU can start the context switch and processing. The kernal needs to allow for the above list so that the interrupt can be handled and processed as fast as possible. Obviously, the faster the stream of interrupts, the more horsepower is required to process them. Lets face it, an interrupt every 100usec or so will overwhelm a PC or Workstation unless it has that singular purpose - even then it will be close. Of course a poorly designed OS will not make matters any better. When you combine the type of Kernal described above with fast hardware, you can achieve a deterministic system. Even with the Kernal by itself, you can improve the performance of the given hardware considerably and provide determinism at some other level (i.e., everyone's definition of "real-time" is dependent upon their application - this ranges from msec to "hard real-time" in the usec range). Harris' definition of real-time is usec to the extent that we provide a 250 nanosecond system clock that provides the user with 1 usec granularity for use with frequency based schedulers, event based schedulers, et. al.. Hope this helps a bit. I have not included alot of detail, but rather, given concepts and hints as to how maximal numbers can be guaranteed. If you have further questions, let me know. Steve -- Stephen C. Daukas | sdaukas@csd.harris.com Harris Corporation | uunet!travis!misg!sdaukas Computer Systems Division | (617) 221-1834, (617) 221-1830 "Old MacDonald had an agricultural real estate tax abatement."