Re: Using Global Variables

[mcsun!uknet!stl!crosfield!pdg@uunet.uu.net (paul goffin)]

In article <16864C1E7.M19481@mwvm.mitre.org> M19481@mwvm.mitre.org writes:
>In article <1992Sep16.152620.9286@nosc.mil>
>sampson@nosc.mil (Charles H. Sampson) writes:
#>In article <15390@suns5.crosfield.co.uk> pdg@crosfield.co.uk (paul goffin)
#>writes (in an article on Ada compiler pricing):

#>>new way of managing "global variables" - Yes, nasty as they are,
#>>you do sometimes have to use global variables in the real world!)
#>>there was a nasty shock in the price of the compilers.

#>     I'd like to hear more about this need to use global variables in
#>the real world, from Mr. Goffin and anyone else.  I can't remember the
#>last time I used one in an Ada project, and I think what I do is pretty
#>real world stuff.  (Well, I do contract to the U. S. Navy, but that's
#>close.)

#The main reason I've heard used to justify the use of global variables is
#performance of a real-time system.  The argument goes that the overhead of

Yes, that's part of it.  I worked in flight simulation.  As well
as the (perceived) need to avoid paramter passing delays, (actually
we measured those, they're not as bad as folklore would have one
believe)  the big need is to share large amounts of data at high
speed between multiple computer systems.

In a flight simulator, nothing is actually encapsulated.  Although
one might like to model the aircraft aerodynamics as a closed task
which only replys to requests for, say "current aircraft latitude"
the actual requirement is quite different.  Not only must those
requests be satisfied, but quite a lot of what _should_ be internal,
local data must also be exported.  I'm talking about last times
values, intermediate values etc.  This is to service the
"record/replay" system.  Here, the simulator is required to replay
the last few mins of a flight and then the pilot takes over and
tries again.  The number of things that have to be stored is
huge.  Making the computer hardware architecure fit a nice _closed_
software model would be amazingly expensive.  So it's not done.

The tried and trusted way to do this in the industry is to share
memory by high speed DMA systems.  In FORTRAN systems, these
shared memory areas are overlayed with COMMON blocks.  In Ada,
I used address clauses to point at data in those areas.  The memory
is global;  the data is global and is accessed (read by) many systems;
only a very few systems actually write to specific data items.

It does require a lot of planning to manage that global data.  On
large simulators it has become a full time job just to adapt a
standard "database" to the new simulated system.

Most people in simulation would like to get away from this
way of doing things (well, actually those who have made a
career out of managing the data are quite happy, but then
they would be!).  Unfortunately, the hardware just ain't
good enough yet.  (It may never be,  as the hardware improves
the requirements of the simulator increase too!)

Paul
-- 
+-------------+-------------------------------------------------------+
+ Paul Goffin +  Crosfield Electronics Ltd. U.K.  +44 442 230000x3357 +
+             +  Opinions expressed are mine! (Yours for a small fee) +
+-------------+-------------------------------------------------------+