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.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 27 Oct 92 04:06:09 GMT From: seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman) Subject: Re: Real time and concurrency (was: What is real-time?) Message-ID: <1992Oct27.040609.24215@seas.gwu.edu> List-Id: 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." ------------------------------------------------------------------------