Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!uw-beaver!uw-june!ka
From: ka@cs.washington.edu (Kenneth Almquist)
Newsgroups: comp.unix.wizards
Subject: Re: Real Time UNIX (was: Re: How do you tell a wizard?)
Summary: Discussion of MERT and UNIX/RT
Message-ID: <9509@june.cs.washington.edu>
Date: 17 Oct 89 07:27:47 GMT
References: <21153@adm.BRL.MIL> <17150@rpp386.cactus.org>
Organization: U of Washington, Computer Science, Seattle
Lines: 61

> In article <21153@adm.BRL.MIL> Kemp@DOCKMASTER.NCSC.MIL writes:
>> Or by "real-time" do you mean "anything under 10,000 usec"?  :-)

In case anyone is confused by this: "real time response" does not
mean "fast response"; it means "response within a certain time bound."

The time bounds for the UUCP communication protocol, for example, are
measured in seconds.  This means that under standard UNIX, which does
not do real time scheduling, UUCP will not work under certain types of
heavy loads.  Real time applications are more likely to have time
bounds measured in milliseconds or microseconds, but they don't have
to.

jfh@rpp386.cactus.org (John F. Haugh II) writes:
> I was under the impression there was a real-time UNIX from AT&T
> as I saw references to UNIX/RT ages ago.
>
> Also, I saw references to MERT in the 1978 BSTJ UNIX edition.
> Isn't this available for hosting real-time UNIX implementations?

MERT stands for "Multi-Environment Real Time".  UNIX/RT is just a
later name for the same system.  MERT was a structured operating
system, in contrast to UNIX, where the kernel was one big blob.

It was an interesting system, but not exceptionally good for real time
work (despite the name).  You could write kernel processes, which were
similar to UNIX device drivers.  You could also write supervisor/user
processes, which are similar to UNIX processes.  A supervisor/user
process had a supervisor address space and a user address space.  To
run a UNIX program, you placed a UNIX emulator in the supervisor
address space of a process and the UNIX program in the user space.

Getting real time performance out of a kernel process was very
similar to getting it out of a UNIX device driver.  To get real time
performance out of a supervisor/user process, you had to deal with two
issues:

First, the scheduler had to select the right process.  The priority
of most MERT processes changed based upon factors such as CPU usage.
However, you could set processes to a fixed high priority.  You could
not request anything like deadline scheduling.  Priority scheduling is
adequate for many real time applications, but the programmer has to
determine what the priorities should be, and there are situations
that deadline scheduling will handle that priority scheduling cannot.

Second, once the scheduler selected the right process it had to start
the process running.  The UNIX emulator avoided concurrent accesses
to data structures by inhibiting context switches during system calls
(except when the system call explicitly blocked).  This meant that if
you used the UNIX emulator, you had to add the execution time of the
longest system call to the basic context switch time.  In addition,
if your process was swapped out when the scheduler selected it, the
process would have to be swapped in.  MERT allowed you avoid this by
locking your process in memory.

MERT support for the PDP-11 was dropped primarily because if you
wanted to run UNIX processes, native UNIX was faster.  A variant of
MERT called DMERT runs on AT&T's 3B20 Duplex machines.  MERT was never
ported to any other machines.  System V picked up the process locking
feature (see plock(2)) but not the fixed process priorities.
				Kenneth Almquist