Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn ) Newsgroups: net.unix-wizards Subject: Re: unix & real time -- is a rewritten UNIX still UNIX? Message-ID: <5727@brl-tgr.ARPA> Date: Sun, 11-Nov-84 20:29:42 EST Article-I.D.: brl-tgr.5727 Posted: Sun Nov 11 20:29:42 1984 Date-Received: Tue, 13-Nov-84 01:24:32 EST References: <39@uwvax.UUCP>, <5633@brl-tgr.ARPA> <9785@watmath.UUCP> Organization: Ballistic Research Lab Lines: 33 > > [That UNIX does not do real-time stuff well] is an old myth based partly > > on fact. > > > > [List of drawbacks was here.] > > > > All these drawbacks can be overcome by a competent UNIX system programmer. > > UNIX can do anything if you just rewrite this or that. Anyone doing real-time programming has to write some nitty-gritty stuff. My point was that it is no harder to do this on UNIX than on any other system (e.g., VMS). The actual kernel changes alluded to amounted to (a) addition of a plock() call, now standard in UNIX System V. (b) addition of a real-time queue in the scheduler. (c) provision of a smart device driver for the A/D interface. I did (a) and (b) in a matter of hours. (John Quarterman showed me how to do (a) with very little effort.) A preliminary version of (c) was done by someone else and rewritten by Quarterman in a few days, along with the matching user-mode double-buffered data acquisition process. These are hardly major changes to UNIX, nor is it unreasonable to ask that the real-time implementor do a bit of work like this. It would certainly be nice if future UNIXes would provide strict priority scheduling and perhaps the 7th Edition phys(2) call to make it even easier for the real-time programmer. It would also be nice if the overly conservative critical region locking in the kernel were replaced by semaphores (I think the 3B20A UNIX kernel has this) for finer control of interrupt latency. Anyone who tries to develop a significant real-time application without the means to fix problems caused by the operating system implementation is asking for trouble. Anyone who thinks he is going to get good real- time response on a timesharing system without a bit of work is a fool.