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=1.6 required=3.0 tests=BAYES_50,FROM_NO_USER
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: Wed, 23 Sep 92 10:01:39 CDT
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Subject: Re: Using Global Variables
Message-ID: <9209231501.AA03051@efftoo.boeing.com>
List-Id: <comp.lang.ada>

mcsun!uknet!stl!crosfield!pdg@uunet.uu.net  (paul goffin) says:

>The tried and trusted way to do this in the industry is to share
>memory by high speed DMA systems.

Yes, it is.  But!  DMA (reflective memory, SCRAMnet, and the others)
communicate by sending messages over a medium.  Physical media are
subject to errors.  And if retransmission is provided by the hardware
(it isn't always) you have potential data synchronization problems.
Not only that, but transfer is *not* instantaneous.

Your managers need to know what happens in the event of errors, what
happens when the equivalent of a BERR occurs (CPU2 is reading while
CPU1 is writing a *record*), and so on.  Ask the manufacturers of these
boards, and you'll get scary answers.

For example, a couple of them told me "Well, you'll have to write software
to handle it."  Which means that your application code, instead of
"simply writing to memory" has to do all kinds of gymnastics before
and after every memory store in order to be safe.

What we find in the simulation business (I only speak for 12 years,
about half in Fortran and half in Ada) is that the little intermittent
glitches are cured by moving modules around in the rate tables until
the glitches disappear.  The great simgate coverup!  You're having
data synchronization problems NOW!

>Most people in simulation would like to get away from this
>way of doing things 

Try the Mod Sim architecture!  At least in Mod Sim you explicitly send
and receive data from a "virtual network" so you know what you're about.
I'm currently at work on an engineering Design Guide for Mod Sim
which includes such things as multiple segments on one CPU and the
wonderful stuff in the SEI's Air Vehicle Structural Model (I really
love that Structural Model except for the explicit shared memory,
which is IMHO very easily "fixable" -- they, of course, might not
regard it as a fix, but as a corruption).

Since I'm one of the architects and implementers of Mod Sim, I'm scarcely
an unbiased observer here!  But at least our management have been very
open to Mod Sim when the problems of shared memory were explained to
them.  Yours may be, too.

You'll always run into salespeople (in the sim biz, it's often Encore)
who will tout shared memory to your managers.  Just make sure your
skeptics are in the meeting.  This isn't a slam on Encore or any other
salespeople, BTW; they have a responsibility to present their products
to their best advantage.  We have a responsibility to be smart shoppers,
so everything's cool.

Their big pitch is that "you can reuse your existing code" but unless
your code is pretty special, you know your old code doesn't work that
well and could stand a good redevelopment into Ada, proper data flow
control, and so on.

Not only that, but as we proved on ASVP in 1987 (and seem to be
re-proving year after year) you only get the integration-time payoffs
of Ada when you redevelop.  Fortran in Ada's clothing carries with
it all the old problems of Fortran.

Good luck to you!
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+