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

[seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman)]

In article <719931680.25559@minster.york.ac.uk> mjl-b@minster.york.ac.uk (Mathe
w Lodge) writes:
>>
>>How many languages (other than Ada) actually provide support for
>>concurrency (as opposed to getting it from the OS)?
>
>The book covers Ada, Modula, Modula-2 and occam, all of which provide
>concurrency features. Other concurrent languages get a mention, but the
>above are the "main" langauges used.
>
>>Does this mean
>>that there was no such thing as real time software until Ada was
>>available? 
>
>Of course not. My point is that a concurrent language makes the expression
>and maintenance of real-time programs far easier. Real time software
>is most often inherently concurrent, and it makes the job so much harder if
>those concurrent tasks have to be forced into a sequential form.
>
[good stuff deleted]

Not only was lots of real-time software written without tasking constructs
(indeed, still is), lots of good software has been written in Fortran
(with no record types or recursion), Basic (no procedure parameters,
except in certain dialects), and, indeed, assembler.

It is fundamental computer science that we can solve any computable
problem using only machine language; indeed, using only Turing machines
with binary alphabets. But why would we want to?

The point here is that over the decades we have added constructs to
languages in order to support application needs, particularly the
_human_ needs we describe as all the -ilities (maintainability,
readability, etc. etc.). Tasking is really no different from all
the other higher-level constructs in that regard. 

The answer to the question "Does Ada really need tasking?" (or better,
"Does real-time programming really need tasking?"), the only honest
answer is "of course not!" On the other hand, those of us who favor
building language support for things, instead of doing everything
at machine-language level, would argue that it sure helps.

That R/T folks find tasking "not fast enough" to meet their needs in
specific projects, gives me a sense of deja vu. In the 70s, when 
"structured programming" was the rage, using procedures to break up
programs - mainly to improve _human_ productivity - was often blasted 
as hopelessly academic, because compilers couldn't deliver the goods
efficiently. Remember those days?

In the end, compilers did a better job, computers speeded up, 
and hardware architects gave us stack machines to support procedure calls. 
Not many people would give strong arguments against procedures these days.

Undoubtedly there are some functional holes in the tasking model; some 
are plugged by Ada-9X. But the basic model is, IMHO, sound, and if we
actually use it, instead of just complaining about it all the time, our
compiler folks and machine architects will find more efficient ways
to support it. The Rational machine (on the hardware side) and POSIX
threads (on the software side) are examples of how this is already
happening.

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.

Cheers -

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------