chris@mimsy.UUCP (Chris Torek) (08/23/87)
>In article <253@etn-rad.UUCP> jru@etn-rad.UUCP (0000-John Unekis) claims: >>... UNIX does not handle real-time applications (such as >>interrupt handling) very well, In article <2862@psuvax1.psu.edu> steve@gondor.psu.edu (Stephen 2. Williams) writes: >Here I agree, but not because of what unix is, but how unix is implimented. >Interrupts are not all that clumsy to deal with in unix, and there >is actually even some structure and cleanliness here, but the process >structure of the unix kernal isn't. A context switch is made a bit messy >by the fact that a process's having to modes: user mode and kernal mode. >An interrupt does not switch the context like it could, making the >process in kernal mode make the decision. I can imagine a UNIX that >would handle interrupts efficiently, but the internals would be different. I cannot quite figure out what is meant. Unix processes do have two `modes', kernel and user. More precisely, a process can be running in either user mode or kernel mode, and there are data structures associated with each process that belong to the kernel and are only accessible while in kernel mode, e.g., the user ID of the process. Any information transferred between the two modes must move through well-defined interface; traditionally this is limited to system calls and traps, although newer Unix systems may move information through `wider' interfaces such as the virtual memory hardware. But none of this has anything to do with efficient interrupt handling! Interrupt handling is dictated by the hardware. Typically an interrupt simply pushes the current PC and status onto an interrupt stack, changes the status to kernel mode, and sets the PC to some fixed value (often read through a `vector table'). The code at this location must arrange for the interrupt to *do* something; this often involves rescheduling and context switching. If it is a user process that wanted the interrupt, obviously that same user process must run in order to do that something, whatever it is. Many Unix schedulers, including the stock scheduler in any 4BSD release, do indeed get in the way of `real time' programming (whatever that means to you). Too, some machines---e.g., Vaxen---are not very good at context switching. The only ways to improve this are to use different hardware or to avoid the context switch, usually by locking the `real time' process in as the only runnable job. The latter tends utterly to destroy multi-user performance whenever `real time' processes are running, unless the machine is a symmetric multiprocessor. People who modify the Unix scheduler to do this, or those who use certain VMS facilities, apparently do not mind. Another approach is to move the entire `real time' process into the kernel. Here not only is the code always available, but all the interprocess address space protection that makes context switching so slow is removed as well. It should be unsurprising that this makes debugging more difficult. Furthermore, many Unix systems have rather primitive kernel debugging facilities. Nonetheless this approach has worked well in the past for a number of people. By working at the very lowest programming level---the point where the interrupt vector begins---you can make your machine field interrupts as fast as it is physically capable. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris