From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_20 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 19 Oct 92 13:02:59 GMT
From: prism!jm59@gatech.edu  (MILLS,JOHN M.)
Subject: Re: What is "real-time"?
Message-ID: <71743@hydra.gatech.EDU>
List-Id: <comp.lang.ada>

In article <BwA7oy.6Mn.1@cs.cmu.edu> dstewart+@cs.cmu.edu (David B Stewart) wri
tes:
>In article <1992Oct16.213820.28793@col.hp.com> tbc@col.hp.com (Tim Chambers) w
rites:
>>First I'll explain the approach which is used in our organization.  Rather
>>than define "real-time" software, we break it into two categories:
>>"time-sensitive" and "time-critical."  Time-sensitive software is that for

[  deleted ... ]

We could fine-tune the definition of real-time software indefinitely, but I
would be interested in comments as to _how_ time constraints affect 
software development, from requirements definition through testing.

My experience had been almost entirely in systems with interrupt-driven
response to time-critical (by T. Chambers' definition) conditions, and
usually to the time-sensitive activities as well, and a clear definition
of what activities were in which category.  We are now working on a
three-processor, six-task radar controller written in XDAda; while I am
confident we can meet our [somewhat vague] task response targets, I
do not believe we dealt with speed requirements in an intelligent way
from the beginning of our project.  We just said: "we can always use a
faster processor," and so forth, and _could_ have gotten hung, since
no clear interdependence of our tasks was expressed nor translated into
testable requirements.

This situation was aggravated by what appears to have been reluctance
on the part of our software designers to directly consider the computer-
or system-hardware performance and shortcomings in specifiying and
designing the software.

I write that in order to raise questions of method and approach, and
move the discussion onward from "changing 'glad's to 'happy's", as
one of my customers described a diminishing-returns editing situation.  It
would also be nice if we avoided [for a few days] the evergreen threads:
  "Why I love/hate Ada more/less than C++", and maybe
  "Why I love/hate Ada tasking more/less than Unix."  [;*>)

Regards --jmm--

-- 
John M. Mills, SRE; Georgia Tech/GTRI/TSDL, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59
Internet: jm59@prism.gatech.edu
 "f U cn rd dis, U mst uz Unix!!!"  ...jaw