Re: "Common" data

Re: "Common" data

[Robert I. Eachus]

In article <9410121737.AA28756@eurocontrol.de> Bob Wells #402 <wel@EUROCONTROL.DE> writes:

 > Where abouts in the LRM does it say that I will only have one copy
 > of the variable T in the following code? This is naturally what you
 > would expect, that A.New_T_Value and B.New_T_Value would be working
 > on the same T, but is this defined in the LRM?

 > This is a trivialization of some comms code delivered to us, and we
 > wanted to see if the behaviour was defined by the LRM.

   You could start with RM 9.11 Shared Variables.  If you can write a
body for Update_T which complies with the assumptions of pragma
Shared, go for it.  Otherwise, in Ada 83, the body of Update_T will
need to use a task to insure consistancy, or an implementation
provided semaphore package.  (Basically 9.11 says that tasks must not
store values in registers across synchronization points, and pragma
Shared can be used to create additional synchronization points for a
specific variable.)

   If some of the updates are done by a mechanism outside the Ada
program, many Ada compilers provide a pragma Volatile to say that each
reference must read or write main memory.

   Hope this helps.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

"Common" data

[Bob Wells #402]

G'day,
Where abouts in the LRM does it say that I will only have one copy
of the variable T in the following code? This is naturally what you
would expect, that A.New_T_Value and B.New_T_Value would be working
on the same T, but is this defined in the LRM?

This is a trivialization of some comms code delivered to us, and we
wanted to see if the behaviour was defined by the LRM.

---------------------------------------
package Common is

  procedure Update_T;

end Common;

package body Common is

  T : Integer;

  procedure Update_T is

  begin

    ..
    code which updates the variable T;
    ..

  end Update_T;

end Common;

---------------------------------------

package A is

   procedure New_T_Value;

end A;

with Common;
package body A is

  procedure New_T_Value is

  begin

    Common.Update_T;

  end New_T_Value;

end A;

---------------------------------------

package B is

   procedure New_T_Value;

end B;

with Common;
package body B is

  procedure New_T_Value is

  begin

    Common.Update_T;

  end New_T_Value;

end B;

---------------------------------------

with A;
with B;
procedure Main is

begin

  A.New_T_Value;

  B.New_T_Value;

end Main;

Any confirmation of this would be greatly appreciated.

Thanks!

@                   --------
@          ////  - ( G'day! )
@         (o o)     --------
@ ----oOO--(_)--OOo--------------------------------------------------------
  Bob Wells                             "For every action there is an equal
                                         and opposite government program."
@ INTERNET: wel@eurocontrol.de                 CompuServe:      100272,3004
@ The Ada WWW Server is http://lglwww.epfl.ch/Ada/                 Team Ada
@ For exciting Ada info enter 'finger wel@s4ecawel.eurocontrol.de'

Re: "Common" data

[Tucker Taft]

In article <EACHUS.94Oct12143818@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:

>In article <9410121737.AA28756@eurocontrol.de> 
> Bob Wells #402 <wel@EUROCONTROL.DE> writes:
>
> > Where abouts in the LRM does it say that I will only have one copy
> > of the variable T in the following code? This is naturally what you
> > would expect, that A.New_T_Value and B.New_T_Value would be working
> > on the same T, but is this defined in the LRM?
>
> > This is a trivialization of some comms code delivered to us, and we
> > wanted to see if the behaviour was defined by the LRM.
>
>   You could start with RM 9.11 Shared Variables.  ...

I believe Robert Eachus misinterpreted this question.  I think the
question is very simple and very fundamental -- if two
different compilation units "with" the same package, do you
end up with just one copy of the data of the package, or
might you get one for each "with"?

The answer is most definitely that you get exactly one
copy of the data of the package, no matter how many
times it is "with"ed.  This is so fundamental to Ada
that it may be hard to point to one single place in the manual
that says it straight out.  The introduction to chapter 10 comes 
closest to saying that a program has at most one copy of any given
compilation unit.  Also, when "with" clauses are explained,
they simply talk about making the "with"ed unit "visible."  

A "with" is *not* like an include, it is just a way to identify
the other units that can be referenced.  It has no effect other
than to make the specified unit visible, and to ensure that
when A is included in a program, and A with's B, then B will
also be included in the program.

> ...
>					Robert I. Eachus

-Tucker Taft   stt@inmet.com

Re: "Common" data

[Robert I. Eachus]

In article <CxLDB7.9DI@inmet.camb.inmet.com> stt@dsd.camb.inmet.com (Tucker Taft) writes:

  > I believe Robert Eachus misinterpreted this question.  I think the
  > question is very simple and very fundamental -- if two
  > different compilation units "with" the same package, do you
  > end up with just one copy of the data of the package, or
  > might you get one for each "with"?

  I won't argue about what the original question "meant."  If the
questioner is satisfied, fine.  Otherwise, we can try to refine the
question.  I assumed from the mention of comm code, that the question
had to do with keeping copies of variables in registers.

  > The answer is most definitely that you get exactly one
  > copy of the data of the package, no matter how many
  > times it is "with"ed.  This is so fundamental to Ada
  > that it may be hard to point to one single place in the manual
  > that says it straight out.  The introduction to chapter 10 comes 
  > closest to saying that a program has at most one copy of any given
  > compilation unit.  Also, when "with" clauses are explained,
  > they simply talk about making the "with"ed unit "visible."  

   If this is the issue, then the answer can be deduced by looking at
the elaboration rules.  For instance, for a variable declared in a
package specification withed by several units, look at 10.5(1),
7.2(3), and finally 3.2.1(7): "The object is created."
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: "Common" data

[Keith Arthurs]

In article <9410121737.AA28756@eurocontrol.de>,
 on Wed, 12 Oct 1994 18:37:08 +0100,
 Bob Wells
>Subject: "Common" data
>From: Bob Wells #402 <wel@EUROCONTROL.DE>
>Newsgroups: comp.lang.ada
>Message-ID: <9410121737.AA28756@eurocontrol.de>
>Date: Wed, 12 Oct 1994 18:37:08 +0100
>
>G'day,
>Where abouts in the LRM does it say that I will only have one copy
>of the variable T in the following code? This is naturally what you
>would expect, that A.New_T_Value and B.New_T_Value would be working
>on the same T, but is this defined in the LRM?
>
>This is a trivialization of some comms code delivered to us, and we
>wanted to see if the behaviour was defined by the LRM.
>
[code Snipped]
>>Thanks!>

  In the LRM section 7.3:3 it states that a variable declared in the body of
a package is only visible within this body...  This defines the "visibility" of
the variable as within the package body.  The paragraph goes on to say that
the the value of such a variable remains unchanged between calls issued from
outside the package to subprograms declared in the visible part.  This defines
the "scope" as the life of the program.  So when you call a routine in package
common, no matter where it is being called from, it is working on the same
storage.


Keith Arthurs
McDonnell Douglas Corporation
Disclaimer: I do not intend for the above commentary to reflect any opinions
            of McDonnell Douglas.  If they do its by pure coincidence.

Re: "Common" data

[Norman H. Cohen]

In article <9410121737.AA28756@eurocontrol.de>, Bob Wells #402
<wel@EUROCONTROL.DE> writes: 

|> G'day,
|> Where abouts in the LRM does it say that I will only have one copy
|> of the variable T in the following code? This is naturally what you
|> would expect, that A.New_T_Value and B.New_T_Value would be working
|> on the same T, but is this defined in the LRM?
...
|>
|> This is a trivialization of some comms code delivered to us, and we
|> wanted to see if the behaviour was defined by the LRM.
|>
|> ---------------------------------------
|> package Common is
|>
|>   procedure Update_T;
|>
|> end Common;
|>
|> package body Common is
|>
|>   T : Integer;
|>
|>   procedure Update_T is
|>
|>   begin
|>
|>     ..
|>     code which updates the variable T;
|>     ..
|>
|>   end Update_T;
|>
|> end Common;
|>
|> ---------------------------------------
|>
|> package A is
|>
|>    procedure New_T_Value;
|>
|> end A;
|>
|> with Common;
|> package body A is
|>
|>   procedure New_T_Value is
|>
|>   begin
|>
|>     Common.Update_T;
|>
|>   end New_T_Value;
|>
|> end A;
|>
|> ---------------------------------------
|>
|> package B is
|>
|>    procedure New_T_Value;
|>
|> end B;
|>
|> with Common;
|> package body B is
|>
|>   procedure New_T_Value is
|>
|>   begin
|>
|>     Common.Update_T;
|>
|>   end New_T_Value;
|>
|> end B;
|>
|> ---------------------------------------
|>
|> with A;
|> with B;
|> procedure Main is
|>
|> begin
|>
|>   A.New_T_Value;
|>
|>   B.New_T_Value;
|>
|> end Main;

This kind of question is hard to answer because it is so instinctively
obvious that there should be only one T.  The easiest answer is "Because
the LRM doesn't say anything to the contrary."

Nonetheless, let's see if we can find justification that will satisfy a
language lawyer.  By 3.2.1(7), an object is created when its declaration
is elaborated.  3.9(3) states that the elaboration of a declarative part
consists of the elaboration of its declarative items in order.  (This
implies that each declaration is elaborated once,and each declard
variable created once, each time the declarative part is elaborated.)
7.3(2) states that when a package body is elaborated, its declarative
part is elaborated (once, since nothing is said to the contrary).  (Thus
T is created once each time the body of Common is elaborated.)  10.5(1)
says that bodies of library units needed by the main program are
elaborated before execution of the main program and 10.5(2) specifies
that compilation units are elaborated in a certain order, which implies
that each unit is only elaborated once.  Thus T is created once, before
execution of the main program.

A rigorous proof would entail enumerating every paragraph of the RM and
establishing that no paragraph provides some OTHER circumstance in which
a declared variable is created or a variable declaration, declarative
part, or body of a library package is elaborated.  A more practical
approach is to challenge anybody who claims that there is more than one T
to justify this position using the RM, and to tear his justification to
shreds.

--
Norman H. Cohen    ncohen@watson.ibm.com