NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/realtime/1451

Text File | 1992-12-18 | 2.8 KB | 61 lines

Newsgroups: comp.realtime
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsm!lfd
From: [e-mail] (Lee Derbenwick)
Subject: Re: Real_time systems
Organization: AT&T
Date: Thu, 17 Dec 1992 23:44:30 GMT
Message-ID: <[e-mail]>
Summary: Preemption implies processes; real-time doesn't.
References: <[e-mail]>
Lines: 49

In article <[e-mail]>, [e-mail] (ZAGROS) writes:
> Is it true to say that, preemption is an essential characteristic of
> a real_time system? if not how can we make sure that all tasks will
> meet their deadlines?

"Preemption" assumes that you've got processes to be preempted,
which is already saying way too much.

A classic real-time technique is simply an infinite loop, which
calls one function for each "task" it needs to do.  Each function
is restricted to a maximum operating time (i.e., _they_ can't
have unrestricted loops), and the sum of all these times must be
less than the maximum tolerable latency for any action.  You
don't even need interrupts.

(Of course, vendors of "real-time operating systems" do _not_
want you to consider this approach.  :-)

Lots of elaboration is possible.  Add interrupts to register events
or to support (a very few) short-maximum-latency actions.  The
timing calculations are more difficult, but still trivial compared
to multiple processes.

I worked on one project that had, instead of a fixed loop, a priority
queue of "joblets": ordinary C functions each of which was called to
do some job (or part thereof), and each of which had a maximum
processing time.  If a job required too much time for one joblet, it
was required to save any state it needed, add itself to the queue
again, then return.

This scheme gave much the flexibility of arbitrary multi-programming,
while making synchronization trivial, since there was no preemption
except for interrupt handlers.  Testing was also much simpler, and
it was easy to monitor what was going on in the executing system.
We worried some about the state saving, but it turned out that in
most cases one or two variables (usually a loop counter) was all
that was needed beyond variables already in memory.  "Context switch"
time was much faster than would have been possible for a true
process implementation, and since we were working on an _abysmally_
slow processor, this was important.

This turns out to be rather similar to the way "streams" work in UNIX
System V: a stream module is called as an ordinary function (within
the kernel); it is required to execute, save any state it needs for
future executions, and return.

 -- Speaking strictly for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Holmdel, NJ
 --   [e-mail]  or  <wherever>!att!cbnewsm!lfd