unix & real time -- is a rewritten UNIX still UNIX?

[Doug Gwyn <gwyn>]

> > [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.