NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/realtime/1469

Text File | 1992-12-22 | 4.1 KB | 85 lines

Newsgroups: comp.realtime
Path: sparky!uunet!munnari.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!megadata!andrew
From: [e-mail] (Andrew McRae)
Subject: Re: Real_time systems
Message-ID: <[e-mail]>
Originator: andrew@noah
Sender: [e-mail]
Organization: Megadata P/L, North Ryde, Sydney, Aust.
References: <[e-mail]>
Date: Tue, 22 Dec 1992 04:10:24 GMT
Lines: 72

From article <[e-mail]>, by [e-mail] (Lee Derbenwick):
> 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.  :-)
>
>  --   Lee Derbenwick, AT&T Bell Laboratories, Holmdel, NJ

Having worked on embedded real time systems for 10 years, and
written a number of embedded operating systems on various
platforms, I heartily agree. I see a lot of companies selling
whiz-bang `Real Time' Operating Systems that have complex
priority and preemption schemes; especially true with the
Unix-compatible systems, where non-realtime and realtime tasks
are mixed (IMHO put the real time tasks where they belong - out
of Unix and into embedded systems...)

The complexity of these systems is mostly (I say again, *mostly*,
not *always*) unwarranted and often add to the overall cost
of the system (in terms of memory, CPU, software cost etc.)
In the truly embedded world, it is often better to simplify
the OS and make the processes/tasks running under it `co-operative',
so that timing contracts are met.

Preemption and priorities are a slippery slope; once you
are on them, you quickly slide down into a sticky swamp. Why?
Prioritisation implies preemption - there would be no point in
having a higher priority task if it did not preempt a lower
priority task. If you have preemption, then you have a problem
with synchronisation and locking, especially with shared data structures
such as lists and queues. Fine, you then add semaphores, messaging
and mailboxes so that you can overcome the locking problems, but
you have to ensure that preemption works properly and that
tasks do not get switched in the middle of critical sections. So you
add monitors, or have the concept of priviledge (priviledged sections
do not get switched), and then after each monitor/semaphore you have
checking for preemption... And then you find that your real time
operating system has grown too big and slow for your real time
processing needs, since it spends all its time locking and
messaging and semaphoring and preempting, so you have to
buy a bigger processor with more memory, and buy a more
expensive licence for your whiz-bang real time OS.

I have come to the conclusion that preemption is to be
avoided *if at all possible*, since it carries a lot of
baggage with it. But having said all that, it certainly
has its place outside of the hard real time world, especially
in systems that require some aspects of real time behaviour, such
as responding quickly to user input, yet sharing CPU resources
fairly amongst competing processes, where some processes are considered
higher priority (e.g the X server responding to mouse/keyboard events,
yet while processing large bit images). Threads will help a lot.

Only my opinion, of course.

Andrew McRae            inet:    [e-mail]
Megadata Pty Ltd,        uucp:    ..!uunet!mega.oz.au!andrew
North Ryde  2113        Phone:    [phone]
NSW    AUSTRALIA        Fax:    [phone]