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.8 required=3.0 tests=BAYES_20,FROM_NO_USER
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: Thu, 24 Sep 92 13:10:31 CDT
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Subject: Re: Using Global Variables
Message-ID: <9209241810.AA05785@efftoo.boeing.com>
List-Id: <comp.lang.ada>

holmes@MIMSY.CS.UMD.EDU  (Holmes S. Liao) says (wrt a reconfigurable
air traffic control system):

>I don't see any problem with the design.

Particularly when reconfigurability is a design requirement, neither
do I -- nor, as I've said earlier, when interprocess communication
is required in an environment in which Ada tasking is not fully
supported (e.g., multiple CPUs from multiple vendors on a common
backplane).

What we've got here is a domain-specific software architecture
(sorry about portentiously announcing the obvious).  But I think
what I and some of the other correspondents were trying to say
was that in many domains, given what I hope are known problems with
global memory, other means of communicating within a process and
between processes may be more appropriate.

Further, those other methods may have positive value.  I'm thinking
in particular of the parameter-passing model between elements within
a process, which has been shown over and over again in practice to
have all kinds of benefits: readability, greatly reduced integration
time, ease of debugging, and so on.  I participated in several of
those programs myself, which might explain some of my enthusiasm.

I'm also thinking of the message-passing model used in Mod Sim and
other programs for communicating between processes, where the idea
of "virtual network" and messages as the application's front end
allows applications to be split into geographically separated
segments or put together in the same CPU with zero impact on code
or performance.  Again, I have a personal interest, since I've
done this and was very happy with the results.

To summarize: I believe that despite what tradition in your industry
says, there are alternatives to shared memory for communicating
between parts of a process and between processes.  If you believe,
as I do, that shared memory can cause problems (e.g., race conditions,
otherwise unnecessary requirements for tight coupling) then you may
find that these alternatives suit your problem domain better.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+