Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!newcastle.ac.uk!turing!ncmh
From: Chris.Holt@newcastle.ac.uk (Chris Holt)
Newsgroups: comp.realtime
Subject: Re: What is "real-time" really?
Message-ID: <1990Feb24.195542.21454@newcastle.ac.uk>
Date: 24 Feb 90 19:55:42 GMT
References: <98692@linus.UUCP>
Sender: news@newcastle.ac.uk
Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE17RU
Lines: 29

In article <98692@linus.UUCP> duncant@mbunix.mitre.org (Thomson) writes:
>
>
>Someone asked me recently what real-time really means.  After some thought,
>I answered that real-time systems were simply those {in which the
>timing constraints were so tight that speciall programming techniques
>were required.  Under this definition, a "real-time" system of today may
>become a non-real-time system whan hardware gets fast enough that I can
>program it using any regular old operating system (say plain old UNIX)
>using high level language (no assembly language optimization) and not have
>to worry about my software failing to meet its deadlines.
>~rk
>Anyone care to comment?  What is the best definition of real-time?
>
>Duncan Thomson

This fails to take into account (i) systems that have to wait for
specified periods, and (ii) proofs that given programs are in fact
"fast enough".  I would define real-time programs as ones in which
time is a necessary component of the specification.  It can be
broken down into "hard" real-time, where the price of missing a
deadline is catastrophic, and "soft" real-time, where the cost is
smooth over time.


_______________________________________________________________________________
  Chris Holt, Computing Lab., U. of Newcastle  |  Chris.Holt@newcastle.ac.uk
_______________________________________________________________________________
   "I will show you fear in a handful of bits..."