Return to BSD News archive
Xref: sserve comp.realtime:3613 comp.os.386bsd.development:1133 Newsgroups: comp.realtime,comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!ihz.compuserve.com!mfoley From: mfoley@csi.compuserve.com (M Foley) Subject: POSIX 1003.4 Realtime Scheduling for 386bsd Message-ID: <CC8Lu9.3Iz@csi.compuserve.com> Organization: CompuServe Incorporated Date: Tue, 24 Aug 1993 00:10:56 GMT Lines: 46 I was going to post a constructive critisism to jmonroy's article "Why fix the RTC (Real Time Control) for 386bsd", but since he was flamed to toast, and since that thread has turned into a Jesus-roast, I am starting a new thread. I do work on real-time, supervisory process control systems and am very interested in this general topic with respect to Unix. How about we bend the subject away from device driver specifics and toward Unix real-time extenstions a la POSIX 1003.4? The .4 draft states that the task scheduling mechanism is to be prioritized and preemptive. There are to be scheduling policies, scheduling priorities, and system service calls to support changing of policies and priorities, and relenquishing time. I can post more exact language if there in further interest. What this means simply, is that processes executing in a higher priority "class" will always be run ahead of processes in a lower class. In fact, they may preempt lower priority processes even if the lower priority processes have time slice remaining. OS/2 serves as a good conceptual example. OS/2 provides 4 classes: CRITICAL, HIGH, NORMAL, IDLE. Within each class, there are 32 priorities. At each tick interval, the scheduler searches the process queues for the next process to run. Any CRITICAL process which has become eligible will take priority over, and preempt, any HIGH, NORMAL, etc. processes. Any HIGH priority process will preempt any NORMAL or IDLE process. Etc. Within the class, processes are serviced according to either round-robin or FIFO algorithms. When the process' allocated slice has been consumed, or it waits on system resources, the process is moved to the tail of its class queue. If the process is preempted, it stays at the head of the queue in its class. So much for the summary. 386bsd already implements 32 priority queues and implements a priority aging mechanism which, I believe, is POSIX 1003.4 acceptable. What about expanding this to say 4 X 32 queues and implementing the preemptive thing? I think this is being partially faked now since (rumor has it that) BSD does negative priorities (sorta like an additional class). OS/2's time slice is an unbelievably coarse (for real-time) 32.25 msecs. I'm sure 386bsd's is already better. I don't believe the POSIX standard specifies acceptable slice-time. So -- what? Any interest in this? It would be great to move from here to threads, .4 type signals, async I/O ......