Re: Real time and concurrency (was: What is real-time?)

[dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!sdd.hp.com!zaphod.mps. ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!lph@ucbvax.Berkeley.EDU (La rry Howard)]

In article <1992Oct27.040609.24215@seas.gwu.edu>, mfeldman@seas.gwu.edu
(Michael Feldman) writes:
|>
|> Before rejecting this or that language feature on a project, I argue 
|> as I always have, with the following aphorisms (I didn't make these up):
|> 
|> 1. It's easier to make a correct program fast than a fast program correct.
|> 
|> 2. Fast enough is fast enough.
|> 
|> 3. If it's not, optimize from the inside out. Find the 10% of the
|>    code that does the 90% of the work, optimize it till it's fast
|>    enough, and forget about the rest.
|> 
|> 4. Measure (or at least analyze openmindedly) before deciding. 
|> 
|> 5. You gotta do what you gotta do. But make sure you gotta do it.
|> 

While I don't disagree with what Dr. Feldman has said, I think his aphorisms
focus on "fast" at the expense of what really matters in real-time systems --
predictability.  In systems where the time when computations are performed is
as important as the results of the computations, performance optimization is
_not_ merely a matter of increasing the speed of certain computations.  Local
efficiency optimizations are _not_ local issues in real-time systems, they
relate directly to global scheduling decisions and to the analysis framework
used to predict the performance of the whole from attributes of the parts.

We have found that design strategies which permit the selection of language
features as a part of global design to be an effective way to make early
predictions of system performance.  We do this by understanding the global
design (architecture) in terms of a relatively few design elements which
embody global coordination decisions (communication, activation,
synchronization) in sets of mechanisms associated with the elements.  The
partitioning consists entirely of instances of these elements.  The mechanisms
each design element provides can be mapped to programming language features.
Instances of the elements inherit these decisions by means of software
templates associated with the elements.

We can analyze such a system early in its development by using specifications
of the design element instances to perform design simulation.  The latter
reconstructs the system as synthetic instances of design elements sized
according to their specifications.  The simulation is then studied on the
target virtual machine.  As we consider alternatives for mapping design
element mechanisms to language features in software templates, we can
investigate the run-time implications of these decisions in the context of the
global design.  Of course, this is an example of global optimization --
decisions by the few affecting the many.

We can analyze local optimizations at the global (system) level through
performance variables associated with the instances of the design elements.
Values for these variables (worse-case execution time, period, order,
coherence) are communicated to system designers using specification forms.  As
described above, these performance variables are used to size synthetic
instances of design elements for performance studies using design simulation.
In this way, the effects of local optimizations (as changes in timing) can be
related to the analysis of system run-time behavior.

Finally, I support those who believe that when rejecting Ada tasking we should
be careful not to "throw the baby out with the bath water."  Lots of good work
(for example by the RMARTS project at SEI) has shown that preemptive,
priority-based scheduling with Ada-83 tasks can be used (within certain
constraints) predictably and efficiently for real-time systems, with
advantages over non-preemptive approaches.  The laggards will warm up to it.



 Larry Howard  (lph@sei.cmu.edu)                       |
 Software Engineering Institute, Carnegie Mellon Univ. | Vera pro gratiis.
 Pittsburgh, PA 15213-3890   (412) 268-6397/5857 (fax) |