NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/unix/question/10265

Internet Message Format | 1992-08-21 | 1.6 KB

Path: sparky!uunet!gatech!news.ans.net!cmcl2!adm!news
From: @ada3.ca.boeing.com:[e-mail] (crispen)
Newsgroups: comp.unix.questions
Subject: Real-time Unix
Message-ID: <[e-mail]>
Date: 21 Aug 92 14:38:02 GMT
Sender: [e-mail]
Lines: 31

We have found in our evaluations that we need to go beyond defining
context switching times, etc. in our requirements for Unix systems.

One of the most important things we've found so far is that you need
to know the method by which preemption is implemented.  We have found
(in real Unixes) three schemes:

(1) fully preemptive: when a higher-priority process becomes ready
to run, if the currently running process is a lower priority, it
suspends at once.

(2) clock-preemptive: higher priority tasks do not get resumed until
the next clock tick.  Latency requirements are met by having a
higher clock tick rate or sub-clocks or some such.

(3) "cheat-preemptive": pending processes aren't allowed to become
ready to run except on clock ticks (so that vendors can claim (1)
is true without actually lying).

You also need to know when signals will activate their handlers (same
sort of thing as above).  In fact, one of the worst offenders seems
to be socket code, where the struct socket doesn't get updated except
on clock ticks (Tahoe code?).  Granted, it's nice for select() to know
that what it finds at the beginning of a tick is what it will find at
the end of the tick, but there are applications that don't appreciate
this "feature".

Who can think of some others?  Or are these wrong?

Bob Crispen
[e-mail]