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 09:19:11 CDT	[thread overview]
Message-ID: <9209231419.AA02963@efftoo.boeing.com> (raw)

Larry Howard  (lph@sei.cmu.edu) writes:

>I'm happy to report that the bogeyman has not come and carted us off.  These
>applications have realized their engineering goals of modifiability and ease
>of integration -- as well as efficiency.

No one would doubt that it is possible to make a shared memory model
meet the ilities with the possible exception of scaleability (I like
to call it separability, but what do I know? ;-)  It has been our
experience, also in the flight simulator domain, that (say) moving
the atmosphere functions from one CPU to another causes a real mess
in re-coding, debugging subtle integration problems, etc.

I am aware of the Air Vehicle Structural Model's Export Area (which
no matter how many times I hear it explained I still can't differentiate
from a named common), but I still have some suspicions about things
like data synchronization, subtle order dependencies and so on.

I will simply state that in my personal experience on three flight
simulators in Ada, the code that used shared memory was invariably
buggier and harder to integrate than code that used parameter passing.

>I personally suggest being wary of anyone
>wishing to raise the use of shared variables to the status of mortal sin.

I would also be suspicious of anyone who offers shared memory as a
means of salvation ;-).  Let's compromise and call it a venial sin, shall
we?

Look, we can all code in Assembler in such a way as to capture all the
ilities.  But generally we don't.  The only reason Ada has such nice
things as data hiding and abstraction is to protect us from our own
"sinful" natures.

Finally, Larry, you know from my brief and amateurish paper I sent you
(or think I sent you) what's wrong with shared memory.  In fact, the
Air Vehicle Structural Model (as I understand its current implementation)
requires tight coupling between Subsystems and a period during each
simulation frame for data synchronization, precisely to avoid those
problems.

To sum up, I think that saying "Shared memory is harmless" is
disingenuous because (a) people tend to abuse it, and (b) special care
must be taken with it to avoid race conditions and similar problems of
data synchronization.
+-------------------------------+--------------------------------------+
| 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 14:19 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-09-23 14:19 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 15:01 crispen
1992-09-23 14:26 munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!phillip.edu.au!x01233
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