comp.lang.ada
 help / color / mirror / Atom feed
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Subject: Re: Using Global Variables
Date: Wed, 23 Sep 92 10:01:39 CDT	[thread overview]
Message-ID: <9209231501.AA03051@efftoo.boeing.com> (raw)

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

             reply	other threads:[~1992-09-23 15:01 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-09-23 15:01 crispen [this message]
  -- strict thread matches above, loose matches on Subject: below --
1992-09-29 15:05 Using Global Variables Charles H. Sampson
1992-09-28 20:56 crispen
1992-09-28 15:53 Victor Giddings
1992-09-28 14:51 Jeffrey Stewart
1992-09-28 12:52 crispen
1992-09-25 22:58 netcomsv!iscnvx!news
1992-09-25 21:16 Charles H. Sampson
1992-09-25 17:50 Charles H. Sampson
1992-09-25 17:36 Charles H. Sampson
1992-09-25 16:30 David A. Hasan
1992-09-25 14:01 crispen
1992-09-24 20:02 netcomsv!iscnvx!news
1992-09-24 18:10 crispen
1992-09-24  6:51 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!utcsri!geac!torsqnt!uuno
1992-09-24  3:52 Michael Feldman
1992-09-23 21:13 haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.ed
1992-09-23 19:11 Charles H. Sampson
1992-09-23 14:26 munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!phillip.edu.au!x01233
1992-09-23 14:19 crispen
1992-09-23 13:24 wupost!spool.mu.edu!olivea!bu.edu!inmet!inmet!shafer
1992-09-23  2:44 Holmes S. Liao
1992-09-22 20:14 LEE MARDEN
1992-09-22 17:08 dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.co
1992-09-22 14:54 van-bc!ubc-cs!destroyer!caen!spool.mu.edu!umn.edu!The-Star.honeywell.com!
1992-09-22 12:19 Robert Firth
1992-09-21 21:30 fred j mccall 575-3539
1992-09-21 20:58 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu
1992-09-21 20:37 Michael Feldman
1992-09-21 20:36 Michael Feldman
1992-09-21 20:31 Michael Feldman
1992-09-21 19:23 Robert Firth
1992-09-21 18:32 agate!linus!linus.mitre.org!mwvm.mitre.org!M19481
1992-09-21 16:51 Doug Smith
1992-09-21 14:43 haven.umd.edu!darwin.sura.net!spool.mu.edu!umn.edu!The-Star.honeywell.com
1992-09-21 11:49 cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!wellerd
1992-09-21  8:10 paul goffin
1992-09-21  4:08 cis.ohio-state.edu!news.sei.cmu.edu!lph
1992-09-19  2:28 Michael Feldman
1992-09-18 23:52 Charles H. Sampson
1992-09-18 22:50 Robert I. Eachus
1992-09-18 13:12 crispen
1992-09-17 18:34 Charles H. Sampson
1992-09-17 14:24 kronos.arc.nasa.gov!iscnvx!news
1992-09-16 17:47 agate!linus!linus.mitre.org!mwvm.mitre.org!M19481
1992-09-16 15:26 Charles H. Sampson
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox