Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!sdd.hp.com!hplabs!hpcc05!aspen!hpcuha!hpcuhd!edwardm From: edwardm@hpcuhd.HP.COM (Edward McClanahan) Newsgroups: comp.realtime Subject: Re: Real-Time UNIX: guaranteed context switch times Vs interrupts Message-ID: <106100001@hpcuhd.HP.COM> Date: 23 Feb 91 01:22:52 GMT References: <9102181527.AA02102@ucbvax.Berkeley.EDU> Organization: Hewlett Packard, Cupertino Lines: 78 Rob Jordan asks: > 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. > 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've got no axe to grind, just curious to understand the truth... Stephen C. Daukas responds: > ... > 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. > ... The rest of Steve's posting deals mostly with "performance" issues. Returning to the question, it is important to understand that no "real-time" system can guarantee that a given task will be completed IN THE PRESENCE OF HIGHER PRIORITY TASKS. In any particular system, only the highest priority task (such as responding to the highest priority interrupt) is guaranteed to complete in a specified time. Repeated execution of a higher priority task can indefinately hold off execution of a lower priority task. The maximum context switch times claimed by Harris, Lynx, and all others are IN THE ABSENCE OF HIGHER PRIORITY TASKS (such as responding to an interrupt). Where there is some question is what does a particular "real-time" OS do with tasks of the same priority. Some systems impose a round-robin technique by periodically interrupting a task to check if other tasks at the same priority are ready to run. Other systems rely on tasks giving up the CPU intentionally. The above refers only to what the "real-time" OS can guarantee without the cooperation of the application code and its "real-world" interface. Suppose we have an extremely simple system with only two priority levels 1 and 2, priority 1 being "higher" just to confuse things. Just to pull numbers out of the air, suppose: Interrupt at pri 1 - External hardware interrupts the CPU - "real-time" OS guarantees 100 ticks to respond Interrupt at pri 2 - Round-robin h/w or s/w context switch interrupt - "real-time" OS guarantees 300 ticks to context switch Now, suppose the application s/w and h/w could guarantee: Driver handling pri 1 interrupt will take only 100 ticks to complete H/W will only issue pri 1 interrupts at 1000 tick intervals This last condition (frequency of higher priority interrupts) allows the combination of OS and application to guarantee a 500 tick context switch time (i.e. atmost one pri 1 interrupt can hold off completion of the context switch). Real world systems can often characterize interrupts sufficiently to allow absolute guarantees on such things as context switch times. The "real-time" OS cannot by itself. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Edward McClanahan Hewlett Packard Company -or- edwardm@cup.hp.com Mail Stop 42UN 11000 Wolfe Road Phone: (480)447-5651 Cupertino, CA 95014 Fax: (408)447-5039 Brought to you by Super Global Mega Corp .com