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

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!yal]

In <1992Oct27.040609.24215@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman
) writes:

>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. 

This starts to become an issue of how much stuff belongs in the
language, how much should be kept at the OS or 'environment' level,
and how much would be better served by allowing it to be handled by
outside tools that could evolve faster than a language spec can?

>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?

Vividly.  In fact, at some times we are STILL in those days -- it all
depends on just what the constraints are.

>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.

The only argument against them is if they keep you from meeting the
requirements.  While rarer than it used to be, this CAN still happen
to you. 

>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.

But you can't use it if you can't meet the requirements.  Note that
several people here have been talking about using global shared memory
WITH ADA in order to get sufficient speed.  This is the same way this
sort of thing is done in every other language, so I'm not sure why Ada
would be such a big win in such a case.

>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.

True, within limits.  However, sometimes you can't get there from
here, at which point it's time to look for a faster algorithm and code
arrangement. 

>2. Fast enough is fast enough.

When you can get there from here.

>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.

Sometimes the only way to get there is to tear out great whacking
chunks, rework the algorithm, and write a monolithic mess with shared
sections and global variables.

>4. Measure (or at least analyze openmindedly) before deciding. 

ALWAYS a good idea.

>5. You gotta do what you gotta do. But make sure you gotta do it.

EXACTLY.  And when you gotta, just tell all the various breeds of
bigots to get out of the way and let you get the job done.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.