Using Global Variables

Using Global Variables

[Charles H. Sampson]

In article <15390@suns5.crosfield.co.uk> pdg@crosfield.co.uk (paul goffin)
writes (in an article on Ada compiler pricing):

>So what did I mean by cost?  Well, apart from the training costs
>and the cost of setting up development systems that actually used
>Ada, (New compiler driving scripts, new way of addressing hardware,
>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.)

				Charlie

Re: Using Global Variables

[agate!linus!linus.mitre.org!mwvm.mitre.org!M19481]

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):
>
>>So what did I mean by cost?  Well, apart from the training costs
>>and the cost of setting up development systems that act>>Ada, (New compiler d
riving scripts, new way of addressing hardware,
>>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.)
>
>                                Charlie
 
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
parameter passing is just too high to meet the performance requirements on
the target machine (which cannot be changed), hence global variables.  Now
you may argue that the target machine should have been chosen more wisely,
or the choice delayed until after the software was totally developed so as
to be able to pick the right size machine -- but I imagine that that's what
Mr. Goffin had in mind when he used the term "real world."
 
David - dhite@mitre.org

Re: Using Global Variables

[kronos.arc.nasa.gov!iscnvx!news]

   Aww, c'mon guys.  I was under the impression that, in Ada, there's no
   such animal as a 'global' variable.  There's just 'more' and 'less' local
   variables.  What's wrong (or difficult, or complicated) about a variable
   which is in scope in the principal subprogram?  Assuming your particular
   application calls for it, that is.

                               Trey Haddad (ghaddad@lmsc.lockheed.com)

    These opinions were left on my doorstep, could you give them a good home?

Re: Using Global Variables

[Charles H. Sampson]

In article <92261.25962.LJ10891@LMSC5.IS.LMSC.LOCKHEED.COM> LJ10891@LMSC5.IS.LM
SC.LOCKHEED.COM writes:
>   Aww, c'mon guys.  I was under the impression that, in Ada, there's no
>   such animal as a 'global' variable.  There's just 'more' and 'less' local
>   variables.  What's wrong (or difficult, or complicated) about a variable
>   which is in scope in the principal subprogram?  Assuming your particular
>   application calls for it, that is.

     I assumed that the original poster was referring to variable objects
declared in the visible parts of library packages.  What's wrong with these
is, I thought, well-known.

				Charlie

Re: Using Global Variables

[crispen]

If you're communicating between two CPUs on a common backplane and
your Ada doesn't have multi-CPU-board tasking, then if you want to
communicate between the boards, you're going to have to (a) use some
OS service (e.g., sockets), or (b) pucker up and stick the variable
into common memory.

There are "nice" and "naughty" ways to do this, of course.  Bad
boys and girls declare a data object in a package spec.  In fact,
*really* bad boys and girls declare data objects in package specs
even when they don't need to talk between CPUs.

Now Trey Haddad (ghaddad@lmsc.lockheed.com) sez:

>   Aww, c'mon guys.  I was under the impression that, in Ada, there's no
>   such animal as a 'global' variable.  There's just 'more' and 'less' local
>   variables.  What's wrong (or difficult, or complicated) about a variable
>   which is in scope in the principal subprogram?  Assuming your particular
>   application calls for it, that is.

It's true that you don't *have* to WITH a package with a data object
in the package spec, so the variable is only *potentially* global -- in
the sense that in F*rtr*n you don't *have* to reference a COMMON block,
but that seems to me to be splitting hairs.

As you can tell, I'm a real bigot about data flow control -- pass your
data in your subprogram arguments OR DIE!

Which is why I wonder about designs that use common memory "for speed".
Did these designs begin as data-flow-controlled designs, and the
common memory was retrofitted when the speed *actually* was too slow?
It's hard to complain about that (though, as a dataflow bigot, I've
found that I could always weed a lot of dumb things out of my code
before having to start on weeding out the smart things).

Or did these designs begin as vintage "working" Fortran code that used
COMMONs and there wasn't program time or money enough to redevelop, just
recode?  Or is it the programmer him/herself who isn't able to take
the time to understand and control the data flow in the system?
Those things may be facts of life in the real world, but IMHO they
should be approached apologetically (I'm a good designer, but I wasn't
allowed to be this time) rather than as justifications (Yeah, I use
COMMON -- so what?  It's great design!).

But, like I said, I'm a bigot.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

Re: Using Global Variables

[Robert I. Eachus]

In article <16864C1E7.M19481@mwvm.mitre.org> M19481@mwvm.mitre.org writes:

  > 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
  > parameter passing is just too high to meet the performance requirements on
  > the target machine (which cannot be changed), hence global variables.  Now
  > you may argue that the target machine should have been chosen more wisely,
  > or the choice delayed until after the software was totally developed so as
  > to be able to pick the right size machine -- but I imagine that that's what
  > Mr. Goffin had in mind when he used the term "real world."

  Next time some know-nothing tells you this, throw some benchmarks at
him.  In most modern architectures with most good compilers references
to local variables and parameters are much faster than global memory
references.  The only time it is faster to use a global instead of a
parameter is when the parameter is referenced less than once per
call...

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Using Global Variables

[Charles H. Sampson]

In article <16864C1E7.M19481@mwvm.mitre.org> M19481@mwvm.mitre.org writes (in
response to a question I posed about why anyone needs to use global variables):
 
>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
>parameter passing is just too high to meet the performance requirements on
>the target machine (which cannot be changed), hence global variables.  Now
>you may argue that the target machine should have been chosen more wisely,
>or the choice delayed until after the software was totally developed so as
>to be able to pick the right size machine -- but I imagine that that's what
>Mr. Goffin had in mind when he used the term "real world."
> 
>David - dhite@mitre.org

     On a lot of target architectures the major part of subprogram overhead
in a recursive, stack-oriented language, like Ada, is in setting up the
stack frame, which is often done by a call to a utility routine if the
architecture is hostile enough.  This overhead is paid on any call, even
for parameterless subprograms, in order to allocate space on the stack for
local data.  On the other hand, parameter passage is usually pretty cheap,
depending on the architecture and the cleverness of the compiler writers. 
So, my question now is: For those real-time systems for which global vari-
ables are used instead of expensive parameter passage, was that decision
based on inherent limitations of the hardware, lack of cleverness by the
compiler writers, or poor analysis of the actual costs of parameter pas-
sage?

                              Charlie

Re: Using Global Variables

[Michael Feldman]

In article <1992Sep18.235238.25207@nosc.mil> sampson@nosc.mil (Charles H. Samps
on) writes:

[stuff deleted]

>So, my question now is: For those real-time systems for which global vari-
>ables are used instead of expensive parameter passage, was that decision
>based on inherent limitations of the hardware, lack of cleverness by the
>compiler writers, or poor analysis of the actual costs of parameter pas-
>sage?
>
In my very limited experience working with real-world real-time people,
it's been mostly the last. There's a lot of folklore in real-time systems.
One of the bits of folk wisdom is "parameters are expensive; globals
are cheap." It's easier to just rely on the folk wisdom than to actually
analyze or measure.

Two bits of _my_ folk wisdom:

(1) Fast enough is fast enough. Tweak (only) what you need to tweak.

(2) It's easier to make a correct program fast than to make a fast program
    correct.

Mike Feldman

Re: Using Global Variables

[cis.ohio-state.edu!news.sei.cmu.edu!lph]

Procedural data interfaces show up in many object-oriented designs as services
which objects provide for accessing their instance variables.  Compilers vary
in their abilities to inline and optimize such interfaces.  Shared data (as
variable objects declared in library-level Ada packages) can be a more
efficient alternative to procedurally accessed data, especially when nothing
is really being hidden behind the procedural facade.

We have been involved in the design of several large, real-time Ada
applications (flight simulators) which have used shared memory extensively.
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.  They are among the largest real-time
Ada applications we're aware of.  I personally suggest being wary of anyone
wishing to raise the use of shared variables to the status of mortal sin.



 Larry Howard  (lph@sei.cmu.edu)                       |
 Software Engineering Institute, Carnegie Mellon Univ. | Vera pro gratiis.
 Pittsburgh, PA 15213-3890   (412) 268-6397/5857 (fax) | 

Re: Using Global Variables

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

Re: Using Global Variables

[cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!wellerd]

In article <15452@suns5.crosfield.co.uk> pdg@crosfield.co.uk (paul goffin) writ
es:
>[general comments about the sins of globals]

>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!)
>

Boy, hearing comments like this tells me that we must be WAY out on
the cutting edge of technology!  OK, here's a few myths that I'd also
like to hose about flight simulators:
	1) You can't encapsulate the date (i.e., OO concepts go to
	   hell in sims).

	Nothing can be further from the truth.  True that this was once
	considered the norm, but no longer.  The C-17 sim is an outstanding
	example of correctly encapsulating data according to the "real-world".

	2) The number of "local data" items to be exported (for record/	
	   play, Instructor manipulation, etc.) is too large to permit
	   encapsulation anyway.

	El Toro de Poopoo.  This is a misconception that frequently
	drives sim companies to choosing archaic architectures.

	3) To have a simulator, you must have a huge, standard database
	   to keep track of the data pool.

	*Sigh* Yeah, that's how it WAS being done for the Shuttle sim.
	Talk about a gaggle.  The funny thing was that the engineers 
	ACCEPTED that as "normal".  Makes shivers run down my spine.

This is not a flame, Paul.  I wanted to "world" to know that you don't
have to give up things like encapsulation and sound engineering concepts
to have an efficient real-time, DISTRIBUTED, simulation.  We are doing it
here in Houston, and it works very nicely, thank you.  We intend to 
publish the datails of our accomplishment next year.  Stay tuned for
more details.

-----No, as a matter of fact, I'm not speaking for my company!---------------
David Weller,         | Space Station Training Facility: Like the real
CAE-Link,             | thing, only you can step outside for a breath
Space Technology Div. | of fresh air!
----I'm the Ultimate International Masochist: I speak Ada AND Esperanto!-----

Re: Using Global Variables

[haven.umd.edu!darwin.sura.net!spool.mu.edu!umn.edu!The-Star.honeywell.com]

In article <1992Sep19.022828.11648@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
>
>Two bits of _my_ folk wisdom:
>
>(1) Fast enough is fast enough. Tweak (only) what you need to tweak.

we have extreme throughput requirements.

Re: Using Global Variables

[Doug Smith]

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):
> >
> >>So what did I mean by cost?  Well, apart from the training costs
> >>and the cost of setting up development systems that act>>Ada, (New compiler
 driving scripts, new way of addressing hardware,
> >>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.)
> >
> >                                Charlie
>  
> 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
> parameter passing is just too high to meet the performance requirements on
> the target machine (which cannot be changed), hence global variables.  Now
> you may argue that the target machine should have been chosen more wisely,
> or the choice delayed until after the software was totally developed so as
> to be able to pick the right size machine -- but I imagine that that's what
> Mr. Goffin had in mind when he used the term "real world."
>  
> David - dhite@mitre.org

OK.  Let's get specific.  Assuming that having to `with' a package does
not violate the definition of global, the following is definitely the
declaration of a global variable:

    package Contains_Global is
       Global_Variable : Integer;
    end Contains_Global;

Now I can effectively convert this to declare the variable inside the
package body, but instead of assignment (a predefined procedure with
special semantics), I must provide my own procedures to access it:

   package Convert_Global is
      procedure Put (Value : in     Integer);
      procedure Get (Value :    out Integer);

      pragma Inline (Put, Get);
   end Convert_Global;

   package body Convert_Global is
      Is_This_A_Global_Variable : Integer; ----------- What do you say?

      procedure Put (Value : in     Integer) is
      begin
         Is_This_A_Global_Variable := Value;
      end Put;

      procedure Get (Value :    out Integer) is
      begin
         Value := Is_This_A_Global_Variable;
      end Get;

   end Convert_Global;

In an attempt to limit the potential explosion of discussion about
why one is better than the other--let's try to define the term `Global'
first!  What is the Integer declared inside the package body?

Doug
smithd@software.org

Re: Using Global Variables

[agate!linus!linus.mitre.org!mwvm.mitre.org!M19481]

>OK.  Let's get specific.  Assuming that having to `with' a package does
>not violate the definition of global, the following is definitely the
>declaration of a global variable:
>
>    package Contains_Global is
>       Global_Variable : Integer;
>    end Contains_Global;
>
>Now I can effectively convert this to declare the variable inside the
>package body, but instead of assignment (a predefined procedure with
>special semantics), I must provide my own procedures to access it:
>
>   package Convert_Global is
>      procedure Put (Value : in     Integer);
>      procedure Get (Value :    out Integer);
>
>      pragma Inline (Put, Get);
>   end Convert_Global;
>
>   package body Convert_Global is
>      Is_This_A_Global_Variable : Integer; ----------- What do you say?
>
>      procedure Put (Value : in     Integer) is
>      begin
>         Is_This_A_Global_Variable := Value;
>      end Put;
>
>      procedure Get (Value :    out Integer) is
>      begin
>         Value := Is_This_A_Global_Variable;
>      end Get;
>
>   end Convert_Global;
>
>In an attempt to limit the potential explosion of discussion about
>why one is better than the other--let's try to define the term `Global'
>first!  What is the Integer declared inside the package body?
>
>Doug
>smithd@software.org
 
Yes, I'd call Is_This_A_Global_Variable global, because it can be used by
anyone for any purpose.  The only way to know how it's being used and whether
one procedure may be clobbering the value entered by another procedure would
be to look at every instance of Get and Put in the system and to understand
the relationships between the procedures that they appear in.
 
David

Re: Using Global Variables

[Robert Firth]

In article <1992Sep19.022828.11648@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:

>(1) Fast enough is fast enough. Tweak (only) what you need to tweak.

Don't tweak even when you need to.  In the time it takes you to get the
tweaks correct, there'll be a new version of the machine that is fast
enough without them.

Re: Using Global Variables

[Michael Feldman]

In article <1992Sep21.165108.11129@software.org> smithd@software.org (Doug Smit
h) writes:
>
[heavily edited]

>OK.  Let's get specific.  Assuming that having to `with' a package does
>not violate the definition of global, the following is definitely the
>declaration of a global variable:
>
(1)
>    package Contains_Global is
>       Global_Variable : Integer;
>    end Contains_Global;
>
(2)
>   package body Convert_Global is
>      Is_This_A_Global_Variable : Integer; ----------- What do you say?
>
>      procedure Put (Value : in     Integer) is
>      begin
>         Is_This_A_Global_Variable := Value;
>      end Put;
>
>      procedure Get (Value :    out Integer) is
>      begin
>         Value := Is_This_A_Global_Variable;
>      end Get;
>
>   end Convert_Global;
>
>In an attempt to limit the potential explosion of discussion about
>why one is better than the other--let's try to define the term `Global'
>first!  What is the Integer declared inside the package body?

This thread has been referring, I think, to the example in (1). The
"locally global" variable in (2) is almost unavoidable in Ada, for
reasons having nothing to do with efficiency. State information must
either be kept "locally global", where it is visible to a group of
operations but nobody else, or passed in parameters, which is a
rather foolish violation of abstraction principles.

C, following PL/1's example, and Algol 60's, allows _static_ data
structures to be declared within a subprogram. Ada does not.

Let's stick to case (1) if this thread is going to continue.

Mike Feldman

Re: Using Global Variables

[Michael Feldman]

In article <1992Sep21.144354.6950@saifr00.cfsat.honeywell.com> walls@saifr00.cf
sat.honeywell.com (Gerald Walls) writes:
>In article <1992Sep19.022828.11648@seas.gwu.edu> mfeldman@seas.gwu.edu (Michae
l Feldman) writes:
>>
>>Two bits of _my_ folk wisdom:
>>
>>(1) Fast enough is fast enough. Tweak (only) what you need to tweak.
>
>we have extreme throughput requirements.

OK, in your case fast enough is _really_ fast. No problem.
Then you need to tweak it. Tweaking isn't sinful. My problem is with
those who think they've got to squeeze every microsecond out of their
program, whether it's necessary or not, and then pay a very high price
in all the "-ility" factors.

A third bit of my folk wisdom:

(3) You gotta do what you gotta do.

Mike Feldman

Re: Using Global Variables

[Michael Feldman]

In article <1992Sep21.192325.16479@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth
) writes:
>In article <1992Sep19.022828.11648@seas.gwu.edu> mfeldman@seas.gwu.edu (Michae
l Feldman) writes:
>
>>(1) Fast enough is fast enough. Tweak (only) what you need to tweak.
>
>Don't tweak even when you need to.  In the time it takes you to get the
>tweaks correct, there'll be a new version of the machine that is fast
>enough without them.
>
Amen!

Mike Feldman

Re: Using Global Variables

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu]

In article <1992Sep21.192325.16479@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth
) writes:
>In article <1992Sep19.022828.11648@seas.gwu.edu> mfeldman@seas.gwu.edu (Michae
l Feldman) writes:
>
>>(1) Fast enough is fast enough. Tweak (only) what you need to tweak.
>
>Don't tweak even when you need to.  In the time it takes you to get the
>tweaks correct, there'll be a new version of the machine that is fast
>enough without them.
>

not in real-time embedded applications where every upgrade
requires more and more functionality on the exact same hardware
the original program was written for years ago.  this is known
as "the real world."

Re: Using Global Variables

[fred j mccall 575-3539]

In <1992Sep21.192325.16479@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes
:

>In article <1992Sep19.022828.11648@seas.gwu.edu> mfeldman@seas.gwu.edu (Michae
l Feldman) writes:

>>(1) Fast enough is fast enough. Tweak (only) what you need to tweak.

>Don't tweak even when you need to.  In the time it takes you to get the
>tweaks correct, there'll be a new version of the machine that is fast
>enough without them.

Well, that may be good advice if you are in a research or academic
environment, but out in the real world that simply isn't always a
viable choice.  The size of the brain that you can stuff into a
restricted space (like a missile) is strictly limited.  You may simply
not be able to shove a more powerful processor in there, even if the
contract and the schedule will let you wait around for one.  In
addition, you may be in the process of doing a software upgrade to
make a system more capable, which requires making the new software run
sufficiently fast on the old hardware.

Let's not forget what the primary use of Ada was intended to be, back
when it was designed (i.e., embedded realtime).

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: Using Global Variables

[Robert Firth]

In article <1992Sep21.205841.9148@saifr00.cfsat.honeywell.com> walls@saifr00.cf
sat.honeywell.com (Gerald Walls) writes:

>not in real-time embedded applications where every upgrade
>requires more and more functionality on the exact same hardware
>the original program was written for years ago.  this is known
>as "the real world."

No, that is not the real world.  It is an artificial world created by
an insane contracting and procurement system that has been designed to
do everything except solve the real problem, and do it as expensively
as possible.

"Oh, it's 2167 this, and 2167 that, and 2167 all the way,
 But it's 'get it done', Mr Atkins, when the band begins to play"

(with apologies to Rudyard Kipling, but I remember when the boats had
to sail south, and a lot of commercial minis were quietly carried
aboard, and the L20 million development of the "military" version
just softly and suddenly vanished away)

Re: Using Global Variables

[van-bc!ubc-cs!destroyer!caen!spool.mu.edu!umn.edu!The-Star.honeywell.com!]

In article <1992Sep22.121955.24424@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth
) writes:
>In article <1992Sep21.205841.9148@saifr00.cfsat.honeywell.com> walls@saifr00.c
fsat.honeywell.com (Gerald Walls) writes:
>
>>not in real-time embedded applications where every upgrade
>>requires more and more functionality on the exact same hardware
>>the original program was written for years ago.  this is known
>>as "the real world."
>
>No, that is not the real world.  It is an artificial world created by
>an insane contracting and procurement system that has been designed to
>do everything except solve the real problem, and do it as expensively
>as possible.

no, it *is* real world.  it's not the procurement system as I do
commercial work.  I doubt that Boeing or any airline is going
to have the slightest urge to pay huge $$$$ to replace flight
computers on commercial airliners everytime a new software upgrade
is proposed.  to do so would be stupid.

you must realize that *real world* encompasses a hell of alot
more than mainframe and PC programming.  if you're doing that kind
of work then sure, buy the latest hardware.  now wait three years,
increase the program's functionality 50% and only be able to add
a limited amount of memory to the system and no processor upgrades.

welcome to a whole new real world.

Re: Using Global Variables

[dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.co]

In <1992Sep22.121955.24424@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes
:

>In article <1992Sep21.205841.9148@saifr00.cfsat.honeywell.com> walls@saifr00.c
fsat.honeywell.com (Gerald Walls) writes:

>>not in real-time embedded applications where every upgrade
>>requires more and more functionality on the exact same hardware
>>the original program was written for years ago.  this is known
>>as "the real world."

>No, that is not the real world.  It is an artificial world created by
>an insane contracting and procurement system that has been designed to
>do everything except solve the real problem, and do it as expensively
>as possible.

Well, it's that 'artificial world' that created and sustains Ada.  So,
what does that say to you?

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: Using Global Variables

[LEE MARDEN]

  At the risk of being flamed for continuing to beat a dead horse, could some
summarize the methods available (good and bad) for using shared memory.  I
just started to monitor comp.lang.ada and have a specific problem I'm trying
to solve.  Here goes:  I have a 4D/240 Power series Silicon Graphics computer
running Irix 4.0.1 (Unix) and the Verdix Ada compiler (on order).  The computer
has 4 processors.  The plan is to reuse code as much as possible so I'm 
stuck with one processor running C, another Fortran and the other two Ada.
Each processor needs to communicate with the others.  I'm not sure on the
amount of data, but my first guess would be tons(>1k variables).  My initial
investigate has only lead me to the conclusion that I would have to write
some Ada wrappers around the C routines (shmctl, shmop, shmget) to control
a shared memory chunk, and that all I would get is a pointer to the data
space.  That would make data access very clumsy.  I've heard of some Pragmas
on other systems that allow you to specify that an entire package of variables
be shared, and utilities to perform the maintance thereof.  I hope that's
enough info for someone to respond.  If not, let me know and I'll elaborate
(no pun intended).

 AdvThanksance, Lee Marden
 
-- 
  AdvThanksance,

  Lee S. Marden, lms@swlray.msd.ray.com
  Raytheon Company, Missile Systems Division, Tewksbury, MA 01876

Re: Using Global Variables

[Holmes S. Liao]

In article <1992Sep21.040837.10149@sei.cmu.edu> lph@sei.cmu.edu (Larry Howard) 
writes:
>We have been involved in the design of several large, real-time Ada
>applications (flight simulators) which have used shared memory extensively.

As far as I know, FAA's endeavor to implement the next generation 
distributed, fault-tolerant, real-time air traffic control system also 
uses shared memory extensively. Each workstation reserves an area to
store runtime-adaptable processor Id, facility Id, rank info., and so on.
The area is shared among all local operating units. Some of the info
in shared memory is required for message passing (header). Some others
can be modified by a global monitor on certain occasions (such as
system failure and re-configuration).

I don't see any problem with the design.

//holmes liao

Re: Using Global Variables

[wupost!spool.mu.edu!olivea!bu.edu!inmet!inmet!shafer]

The use of global data is "really" just a case of efficiently implemented
parameter passing.  We could see this clearly if we just considered the
characterization of parameter passing in terms of its operational semantics,
insteaed of full blown descriptive prescriptions.   It's just the difference
between what is "really happening" and how we see fit to describe and map
it.  Optimization can then be viewed as part of compiling, not programming.

Re: Using Global Variables

[crispen]

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

Re: Using Global Variables

[munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!phillip.edu.au!x01233]

In article <1992Sep21.203114.17199@seas.gwu.edu>, mfeldman@seas.gwu.edu (Michae
l Feldman) writes:
> In article <1992Sep21.165108.11129@software.org> smithd@software.org (Doug Sm
ith) writes:
>>
>>	[Discussion of what is a global variable...]
>>
> (1)
>>    package Contains_Global is
>>       Global_Variable : Integer;
>>    end Contains_Global;
>>
> (2)
>>   package body Convert_Global is
>>      Is_This_A_Global_Variable : Integer; ----------- What do you say?
>>
>>[...]--let's try to define the term `Global'
>>first!  What is the Integer declared inside the package body?
> 
> This thread has been referring, I think, to the example in (1). The
> "locally global" variable in (2) is almost unavoidable in Ada, for
  ^^^^^^^^^^^^^^^^

One of my students last year referred to "locally global" variables as

      _REGIONAL_ variables. Seems like a good name to me!


Dale Stanbrough
RMIT
Melbourne Australia
dale@phillip.edu.au

Re: Using Global Variables

[crispen]

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

Re: Using Global Variables

[Charles H. Sampson]

     Several of the entries in this thread have raised the spectre of shared
memory.  Without addressing whether shared memory is good or bad, let's clar-
ify that it's not the point of this thread.  _Global_ is an issue of name
scope, of visibility.  Ada gives perfectly adequate means for accessing
shared memory without requiring that the names of the data in the shared mem-
ory be global (the address clause).  The shared memory is a shared resource,
of course, and must be handled carefully, but the problems of shared memory
are quite different from the problems of global data, at least in Ada.

				Charlie

Re: Using Global Variables

[haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.ed]

In article <20600143@inmet>, shafer@inmet.inmet.com writes:
|> 
|> The use of global data is "really" just a case of efficiently implemented
|> parameter passing.  We could see this clearly if we just considered the
|> characterization of parameter passing in terms of its operational semantics,
|> insteaed of full blown descriptive prescriptions.   It's just the difference
|> between what is "really happening" and how we see fit to describe and map
|> it.  Optimization can then be viewed as part of compiling, not programming.

The use of global variables for communication between program elements has the
virtue of decoupling communication from invocation or synchronization.  This
type of communication can therefore be combined with a variety of coordination
mechanisms.  You have pointed out that global variables can be used to
implement parameter passing on subprogram and entry calls, and that this
decision could be made by a compiler in response to some global optimization.
It could likewise be made by a lead designer and embodied in an architecture.

There can be considerable safety in limiting a design to the
control/communication pairings supported by Ada in the form of subprogram
calls and rendezvous.  These are both predictable and understandable (;').
There may also be considerable power in other forms of coordination, even if
these same forms have been misused in the past.  I think we should only insist
that whatever is used be understandable and predictable.

I guess what I really objected to in this thread was the odor of orthodoxy
when (IMHO) we still seem to be on a fairly steep learning curve.



 Larry Howard  (lph@sei.cmu.edu)                       |
 Software Engineering Institute, Carnegie Mellon Univ. | Vera pro gratiis.
 Pittsburgh, PA 15213-3890   (412) 268-6397/5857 (fax) | 

Re: Using Global Variables

[Michael Feldman]

In article <1992Sep23.092629.13017@phillip.edu.au> x01233@phillip.edu.au writes
:
>> 
>> This thread has been referring, I think, to the example in (1). The
>> "locally global" variable in (2) is almost unavoidable in Ada, for
>  ^^^^^^^^^^^^^^^^
>
>One of my students last year referred to "locally global" variables as
>
>      _REGIONAL_ variables. Seems like a good name to me!
>
I like this! I hope you don't mind if I crib it...

Mike Feldman

Re: Using Global Variables

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!utcsri!geac!torsqnt!uuno]

crispen@efftoo.boeing.com (crispen) writes:

>Which is why I wonder about designs that use common memory "for speed".
>Did these designs begin as data-flow-controlled designs, and the
>common memory was retrofitted when the speed *actually* was too slow?

 Is it possible that you are confusing static variables with variables 
 that are keep on a stack or display. And before someone jumpes on me
 about how memory inefficient that allocating variables staticaly is, 
 a little program flow analsys can be used to overlay unused memory
 areas(I have done it before for a pascal compiler on a machine that
 had no stacks or index registers). The result is a program that looks
 like it has no global variables but runs like it does.

-- 
Alvin Starr                   ||   voice: (416)513-6717
Eyepoint Inc.                 ||   fax:   (416)513-6718
alvin@eyepoint.com            ||

Re: Using Global Variables

[crispen]

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

Re: Using Global Variables

[netcomsv!iscnvx!news]

------------------------- Original Article -------------------------
>cope, of visibility.  Ada gives perfectly adequate means for accessing
>shared memory without requiring that the names of the data in the shared mem-
>ory be global (the address clause).  {surrounding text deleted}

   Not to mention just declaring a package GLOBAL, containing nothing but
shared variables, and 'withing' said package to all units which require
access to these 'global' variables.  :-)

        Trey Haddad (ghaddad@lmsc.lockheed.com)
I found these opinions on my doorstep, will you give them a good home?

Re: Using Global Variables

[crispen]

sampson@cod.nosc.mil  (Charles H. Sampson) says:

>     Several of the entries in this thread have raised the spectre of shared
>memory.  Without addressing whether shared memory is good or bad, let's clar-
>ify that it's not the point of this thread.

Mea culpa, inter alia.  I keep thinking of the way that global visibility
is implemented (as memory).  And if you've got any sort of tasking or 
multiprocess considerations you have at least the possibility of
shared memory.  So I apologize for going from point A to point Q
without touching the bases in between, and for my part in broadening
the topic.

You are certainly right that communication between elements within a
process and communication between processes are two separate things.
I do think, though, that there are global visibility issues for both.
And I think that people writing on this topic were addressing both.

For example:

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

>There may also be considerable power in other forms of coordination, even if
>these same forms have been misused in the past.  I think we should only insist
>that whatever is used be understandable and predictable.

Right on!  I'm not sure I completely accept your notion of "decoupling
communication from invocation or synchronization" but I agree that
"previous offenders" should be given a chance to rehabilitate themselves.

I know that you believe that there are software architectures that
can standardize and template-ize the use of global variables to such an
extent that the practice becomes safe.  I think I do, too.  What I
do wonder about is the non-abstract use of memory (potentially
shared memory in a multiprocess system) to implement global variables.
That's the part I have concerns about.

It feels to me like we've taken our "previous offender", locked him
in a room with only a couple of doors in and out (which we can watch)
but he's (potentially) using the phone to commit crimes.
 
>I guess what I really objected to in this thread was the odor of orthodoxy
>when (IMHO) we still seem to be on a fairly steep learning curve.
 
Double right on!  And another mea culpa if my pedantic style was
mistaken for assurance about my views.  I am presently only sure that
I have doubts.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |     Down with orthodoxy, or DIE!     |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

Re: Using Global Variables

[David A. Hasan]

Comparing an "unencapsulated global" package:

>   package Contains_Global is
>      Global_Variable : Integer;
>   end Contains_Global;


to an "encapsulated global" package:

>   package Convert_Global is
>      procedure Put (Value : in     Integer);
>      procedure Get (Value :    out Integer);
>   end Convert_Global;
>
>   package body Convert_Global is
>      Is_This_A_Global_Variable : Integer; ----------- What do you say?
>
>      procedure Put (Value : in     Integer) is ...;
          [sets Is_This_A_Global_Variable]
>      procedure Get (Value :    out Integer) is ...;
          [returns Is_This_A_Global_Variable]
>   end Convert_Global;


Doug Smith mentions that


>In an attempt to limit the potential explosion of discussion about
>why one is better than the other--let's try to define the term `Global'
>first!  What is the Integer declared inside the package body?

The problem with the term "global" is that is just describes 
to topological- (visibility-) related aspects of the coupling.
However, in the sense of Constantine & Yourdon, there is much
more to coupling that just "who sees what"; the meaning of   
coupling includes "who knows what".

Applying this to the example above, even though the visibility
is essentially the same, the fact remains that
the latter ("encapsulated global") approach permits the
implementor to CHANGE the actual definition of the variable
WITHOUT affecting how clients read and write to it.  Thus
the nature of the client's knowledge about the "global"
is different, and therefore so is the coupling.

Although both approaches can usefully be called "global",
the former ("UNencapsulated global") approach introduces
MORE COUPLING between the package and its clients.  The
term "global" alonge does not distinguish between these.

PS. This is not necessarily a pedantic distinction.  If
    (at some later stage in the evolution of the package)
    the implementor decided that the value of the "global"
    quantity should be CALCULATED based on some other
    information, the latter ("encapsulated global")
    approach would allow the change to be made only in 
    the package of the body, requiring NO changes or
    recompilations of the client's code.  (E.g., polar
    or rectangular representation of complex numbers.)
-- 
 |   David A. Hasan
 |   hasan@emx.utexas.edu 

Re: Using Global Variables

[Charles H. Sampson]

In article <92268.46318.LJ10891@LMSC5.IS.LMSC.LOCKHEED.COM> LJ10891@LMSC5.IS.LM
SC.LOCKHEED.COM (Trey Haddad) writes:
>------------------------- Original Article -------------------------
>>cope, of visibility.  Ada gives perfectly adequate means for accessing
>>shared memory without requiring that the names of the data in the shared mem-
>>ory be global (the address clause).  {surrounding text deleted}
>
>   Not to mention just declaring a package GLOBAL, containing nothing but
>shared variables, and 'withing' said package to all units which require
>access to these 'global' variables.  :-)

     With the result that anybody who needs to access anything in shared
memory now has full access to everything in shared memory.  Ah, informa-
tion hiding, what has happened to you?

				Charlie

Re: Using Global Variables

[Charles H. Sampson]

In article <1992Sep21.165108.11129@software.org> smithd@software.org (Doug Smit
h) writes:
->OK.  Let's get specific.  Assuming that having to `with' a package does
->not violate the definition of global, the following is definitely the
->declaration of a global variable:
->
->    package Contains_Global is
->       Global_Variable : Integer;
->    end Contains_Global;
->
->Now I can effectively convert this to declare the variable inside the
->package body, but instead of assignment (a predefined procedure with
->special semantics), I must provide my own procedures to access it:
->
->   package Convert_Global is
->      procedure Put (Value : in     Integer);
->      procedure Get (Value :    out Integer);
->
->      pragma Inline (Put, Get);
->   end Convert_Global;
->
->   package body Convert_Global is
->      Is_This_A_Global_Variable : Integer; ----------- What do you say?
->
->      procedure Put (Value : in     Integer) is
->      begin
->         Is_This_A_Global_Variable := Value;
->      end Put;
->
->      procedure Get (Value :    out Integer) is
->      begin
->         Value := Is_This_A_Global_Variable;
->      end Get;
->
->   end Convert_Global;
->
->In an attempt to limit the potential explosion of discussion about
->why one is better than the other--let's try to define the term `Global'
->first!  What is the Integer declared inside the package body?

     As an early poster to this thread pointed out, the concept of global
is relative.  Nonetheless, I think it best to reserve the term for its
classical usage: Something is global if it is visible throughout the en-
tire system.  Of course, in Ada nothing is automatically visible other
than the things in package Standard, so we have to bend the classical
usage a little to acknowledge the with clause.  Thus that variable inside
the package is not global.  The term "regional", suggested by a recent
poster, is a good one.

     As that early poster was implying, you have to be careful with
regional data.  If their namescopes become large most of the classical
problems of global data arise.

				Charlie

Re: Using Global Variables

[Charles H. Sampson]

In article <16869CC93.M19481@mwvm.mitre.org> M19481@mwvm.mitre.org writes:

> [re Doug Smith's example of an integer variable (Is_This_A_Global_Variable)
> encapsulated in a package body with entry procedures Get and Put for reading
> and writing.]

>Yes, I'd call Is_This_A_Global_Variable global, because it can be used by
>anyone for any purpose.  The only way to know how it's being used and whether
>one procedure may be clobbering the value entered by another procedure would
>be to look at every instance of Get and Put in the system and to understand
>the relationships between the procedures that they appear in.

     A point of encapsulation, I think its main point, is to hide the repre-
sentations of data from their users.  A very complex data structure encapsu-
lated in a package might have many procedures and functions implemented to
access it.  After all, data that no one can read or write is not very useful.
Just because these accesses have been supplied and somebody might introduce
a bug by misusing one of them doesn't make the data global.

				Charlie

Re: Using Global Variables

[netcomsv!iscnvx!news]

------------------------- Original Article -------------------------
>    With the result that anybody who needs to access anything in shared
>memory now has full access to everything in shared memory.  Ah, informa-
>tion hiding, what has happened to you?
                                                          >             Charlie

   True, but the problem domain under discussion seemed centered around
large memory areas with common access requirements.  For a more discriminating,
less refined (yes, I do believe that parameter passing is more refined and
controllable), method one could open the pandora's box of:

package GLOBAL_1 is ...   -- regionals associated with some functionality
package GLOBAL_2 is ...   -- regionals associated with another functionality
..  -- etc.

   Synchronization is left as an exercise for the masochist.  :-)

   Trey Haddad (ghaddad@lmsc.lockheed.com)
These opinions were left on my doorstep, would you give them a good home?

Re: Using Global Variables

[crispen]

alvin@eyepoint.com (Alvin Starr) asks:

Me>Which is why I wonder about designs that use common memory "for speed".
Me>Did these designs begin as data-flow-controlled designs, and the
Me>common memory was retrofitted when the speed *actually* was too slow?

AS> Is it possible that you are confusing static variables with variables 
AS> that are keep on a stack or display. 

I was taking as my two alternatives: (a) variables which are declared
in package specs, and (b) parameters which are passed with function
calls.  Obviously, there are more alternatives, but let's use these
for now.

In the latter ("data-flow-controlled") mechanism, there is a requirement
to copy variables onto the stack, call the subprogram, and copy them off
the stack.  In the former, most compilers I know of simply declare the
variable as global, in which case, there's simply a memory fetch or store.

That's the reason that people have said that data-flow-controlled
designs "waste CPU cycles".

In fact, every time I have done a data-flow-controlled design, it
has executed *faster* than the global-data design it replaced.  There
seem to be three reasons for this:

	(a) Data on the stack is generally in cache, while global
	data generally isn't.

	(b) When I go to redevelop the earlier design, I find that
	the programmer (often me) did some dumb things (slow
	algorithms, meaningless variable stores, etc.) that I can
	avoid this time.  I'll restate a point I made earlier: to
	speed up your code, get rid of the dumb things you're doing
	before you get rid of the smart things you're doing.

	(c) Because I'm highly prejudiced toward a data-flow-
	controlled design, I'm highly motivated to make it fast
	to confound my enemies.

And, of course, I get the payoffs of reduced integration time, greater
maintainability, and lack of mysterious glitches for free.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

Re: Using Global Variables

[Jeffrey Stewart]

We are currently working with a design simulator project which will be running 
as either real-time or non real-time, depending on the site where it is 
installed.  One of the engineering goals for this simulator was to be as
run-time configurable as possible, given certain limitations of Ada.

Our approach has been to incorporate some of the concepts of OODBs, where there
is a central allocator of memory to which the objects subscribe, the objects
then receive a pointer to their instance data.  Objects are the only ones that
know about their instance data.  Other access to the instance data is done 
through the OODB services, which can provide pointer access to objects (for the
record/play capability, with the items to be recorded being configurable at 
run-time), or through direct requests for getting or setting the state of a 
given object.  Direct pointer access for record/play is required since some 
kind of look-up mechanism is needed to first find the objects, which is 
certainly not a "real-time" operation.

The only run-time overhead during the actual simulation run involves
pointer access, which we've found to be acceptable.   

Re: Using Global Variables

[Victor Giddings]

In article <1992Sep22.201420.25962@swlvx2.msd.ray.com>, lms@swl.msd.ray.com
(LEE MARDEN) wrote:
> 
> 
>   At the risk of being flamed for continuing to beat a dead horse, could some
> summarize the methods available (good and bad) for using shared memory.  I
> just started to monitor comp.lang.ada and have a specific problem I'm trying
> to solve.  Here goes:  I have a 4D/240 Power series Silicon Graphics computer
> running Irix 4.0.1 (Unix) and the Verdix Ada compiler (on order).  The comput
er
> has 4 processors.  The plan is to reuse code as much as possible so I'm 
> stuck with one processor running C, another Fortran and the other two Ada.
> Each processor needs to communicate with the others.  I'm not sure on the
> amount of data, but my first guess would be tons(>1k variables).  My initial
> investigate has only lead me to the conclusion that I would have to write
> some Ada wrappers around the C routines (shmctl, shmop, shmget) to control
> a shared memory chunk, 

We actually experimented with this with some success (although I still
think it was a bad idea).  We did, however, have unexplained intermittent
crashes.  We speculated that the shmat (using shmaddr:= 0) was returning an
address that the run-time system was re-using for a dynamic allocation. 
Any SGI and/or Verdix gurus wish to comment?

> and that all I would get is a pointer to the data
> space.  That would make data access very clumsy. 
The indirection can be accomplished using one qualification, e.g.
Global_Pool.Data_Element.  Doesn't strike me as any more clumsy than trying
to maintain the data space in the first place.  :-)

> I've heard of some Pragmas
> on other systems that allow you to specify that an entire package of variable
s
> be shared, and utilities to perform the maintance thereof.  I hope that's
> enough info for someone to respond.  If not, let me know and I'll elaborate
> (no pun intended).
> 
>  AdvThanksance, Lee Marden
>  
> -- 
>   AdvThanksance,
> 
>   Lee S. Marden, lms@swlray.msd.ray.com
>   Raytheon Company, Missile Systems Division, Tewksbury, MA 01876

Re: Using Global Variables

[crispen]

Victor Giddings and Lee Marden share some guilty secrets about using
shared memory.  Here's one of mine.  On a multi-board VME chassis
running VxWorks/VADSWorks, we changed the boot configuration file
so that the sysMemTop function in VxWorks thought each VME board
had 64K memory less than it actually had.  This top 64K was used
to pass data back and forth between the boards:

	for Control_Block use at System.Physical_Address (xxxxx);

It worked great, especially when the system crashed, because the
ROM monitor had the ability (under most kinds of crashes) to display
memory in a hex dump even when the OS and all the application
programs were thoroughly hosed.  We knew that 0x3f0004 contained
the service request, etc.

Of course, we had a pretty firm control: one writer, one reader for
a field, and the writer interrupted the reader when it wanted the
reader to read the field.

I really enjoyed this.  It was like the old days in microprocessors,
where you knew were everything was and you treated machines like
machines.  Those were the days...
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

Re: Using Global Variables

[Charles H. Sampson]

In article <92269.56792.LJ10891@LMSC5.IS.LMSC.LOCKHEED.COM> LJ10891@LMSC5.IS.LM
SC.LOCKHEED.COM writes:
>------------------------- Original Article -------------------------
>>    With the result that anybody who needs to access anything in shared
>>memory now has full access to everything in shared memory.  Ah, informa-
>>tion hiding, what has happened to you?
>                                                          >             Charli
e
>
>   True, but the problem domain under discussion seemed centered around
>large memory areas with common access requirements.  For a more discriminating
,
>less refined (yes, I do believe that parameter passing is more refined and
>controllable), method one could open the pandora's box of:
>
>package GLOBAL_1 is ...   -- regionals associated with some functionality
>package GLOBAL_2 is ...   -- regionals associated with another functionality
>..  -- etc.
>

     Try the following:

   PACKAGE BODY Hider IS

      Shared_datum : ...
      FOR Shared_datum USE AT A_shared_memory address;

      ...
      
   END Hider;

     It's possible to engineer the layout of shared memory to some degree
when using this approach, but it requires a compiler that has implemented
some modest sort of address arithmetic.  If speed of access to this datum
is a requirement, it can be obtained in most compilers by inlining the
access routines.

>   Synchronization is left as an exercise for the masochist.  :-)

     Synchronization becomes a lot easier because it's all hidden inside
this package.

				Charlie