Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!ihnp4!fortune!rpw3
From: rpw3@fortune.UUCP
Newsgroups: net.unix
Subject: Re: Unix and real time control - (nf)
Message-ID: <3186@fortune.UUCP>
Date: Sun, 29-Apr-84 23:08:23 EDT
Article-I.D.: fortune.3186
Posted: Sun Apr 29 23:08:23 1984
Date-Received: Tue, 1-May-84 07:06:56 EDT
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 43

#R:sri-arpa:-13200:fortune:26900054:000:2036
fortune!rpw3    Apr 29 19:38:00 1984

UNIX does not provide the real-time features you are probably
used to in DEC operating systems, but if your requirements
are not too complex, there are two "tricks" (often used in
network implementations), one of which may work for you.
Both require that you have kernel (at least driver) sources
and a kernel guru "on-call".

1. You will need a special device driver for your funny hardware
   anyway, right? Simply provide a "ioctl" which waits for the
   next "interesting" event from the interrupt level and returns
   some kind of data about what the event was, etc. If the driver
   "sleeps" at "positive" priority (x >= PZERO), the process will
   be able to swap out while sleeping, and conversely. Swapping
   lessens contention for memory, but gives poorer response.
   This version assumes all of the computation runs in user space,
   and the driver just handles the interrupt data capture.

2. If you can't even stand the time it takes a memory-resident
   UNIX process to "return" from an ioctl, put the ENTIRE real-time
   task in the driver. At system boot time (or whenever), a tiny
   user program opens /dev/realtime (your driver). The driver never
   returns from the open, but runs as a user process in kernel
   mode, sleeping when appropriate. Since it has a "user process",
   it can do disk I/O and other things "user processes" can do.

The overall point is that UNIX has all kinds of "real-time" features
in the kernel (sleep/wakeup and "timeout" [scheduled events]) for
managing the concurrency of its I/O system -- they're just not
(readily) available to user processes. Therefore, the time-critical
portions of your task must run as kernel code. The simplest way to do
this is to bury it in the device driver you use to talk to your hardware.
As I said above, several implementations of network software have taken
this approach.

Rob Warnock

UUCP:	{ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065