Unreferenced lock variables

Unreferenced lock variables

[Simon Wright]

I've been looking at using a 'control by allocation' technique (I'm
sure there's a more standard name, but I can't find it at the moment:
a resource is encapsulated in a type such that declaring an object of
the type allocates the resource).

For example,

  procedure Mark (R : in out Synchronized_Unbounded_Ring) is
    Lock : BC.Support.Synchronization.Write_Lock (R.The_Monitor);
  begin
    Mark (Unbounded_Ring (R));
  end Mark;

where the initialization of Lock calls the appropriate operations on
R.The_Monitor (which is a class-wide access ..) to ensure exclusion,
in this case for a Writer.

Now, GNAT quite properly warns me that Lock is unused; so, having been
bitten this way once, I cast around and found that inserting

    pragma Volatile (Lock);

will eliminate the warning.

However, it doesn't seem to be as legitimate a use as in the recent
thread on Handling Addressing Errors; is there a better way? pragma
Import (Ada, Lock) perhaps? or should I look for a different style?

Re: Unreferenced lock variables

[Tom Moran]

>Now, GNAT quite properly warns me that Lock is unused
There are also other perfectly legal cases where GNAT warns you about
something that doesn't need a warning. 
>    pragma Volatile (Lock);

>will eliminate the warning.
I myself wouldn't clutter good Ada code with spurious and misleading
things like this just to turn off overly conservative compiler
warnings.  If you can do that in an inocuous way, great, but this
particular one is likely to confuse some poor maintainer down the
road.,

Re: Unreferenced lock variables

[Robert Dewar]

In article <x7v4smnszvu.fsf@pogner.moho>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> is there a better way [of avoiding the warning]

why not

 pragma Warnings (Off, Lock);

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Unreferenced lock variables

[Simon Wright]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> In article <x7v4smnszvu.fsf@pogner.moho>,
>   Simon Wright <simon@pogner.demon.co.uk> wrote:
> > is there a better way [of avoiding the warning]
> 
> why not
> 
>  pragma Warnings (Off, Lock);

Because I'm concerned that aggressive optimization (-O3) will
eliminate the lock variable altogether.

The last time this happened was

  Dummy : Foo := Some_Function_With_Side_Effects;

and -O3 ended up without the side effects.

Re: Unreferenced lock variables

[Robert Dewar]

In article <x7vk8viqsla.fsf@pogner.moho>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> Because I'm concerned that aggressive optimization (-O3)
> will eliminate the lock variable altogether.
>
> The last time this happened was
>
>   Dummy : Foo := Some_Function_With_Side_Effects;
>
> and -O3 ended up without the side effects.


Well that would have course have been a significant bug,
and we have never seen any such bug in -O2 mode (-O3
is irrelevant here), nor had any such problem reported
that I can remember. The backend may well remove the
variable itself, but cannot remove the call.

With regard to initialization and finalization, the ARG
just agreed (unwisely if you ask me!) to allow a compiler
to optimize away initialization and finalization for an
otherwise unreferenced variable. GNAT does not take
advantage of this, but it means that to be compeltely
portable, you need to put in a dummy reference to the
variable.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Unreferenced lock variables

[Simon Wright]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> In article <x7vk8viqsla.fsf@pogner.moho>,
>   Simon Wright <simon@pogner.demon.co.uk> wrote:
> > Because I'm concerned that aggressive optimization (-O3)
> > will eliminate the lock variable altogether.
> >
> > The last time this happened was
> >
> >   Dummy : Foo := Some_Function_With_Side_Effects;
> >
> > and -O3 ended up without the side effects.
> 
> Well that would have course have been a significant bug,
> and we have never seen any such bug in -O2 mode (-O3
> is irrelevant here), nor had any such problem reported
> that I can remember. The backend may well remove the
> variable itself, but cannot remove the call.

In what way irrelevant? Am I supposed not to use -O3? or do you just
mean that there is no distinction here between 2 and 3 (I only have
the 3.10 version of the secret manual here, it indicates that -O3 only
adds automatic inlining).

I certainly saw this with GNAT 3.11p, the compiler warned that the
variable was unused, when I compiled -O3 there was a misbehaviour in
my code explainable as above, change the code to achieve the
side-effect via a procedure call in the body and the misbehaviour goes
away. I can try to reconstitute the problem and report it (if it is
indeed a bug to optimize away the initialization of an unused
variable? it struck me at the time that it was much more my fault!)

Re: Unreferenced lock variables

[Robert Dewar]

In article <x7vzp4dscsv.fsf@pogner.moho>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:

> I can try to reconstitute the problem and report it (if
> it is indeed a bug to optimize away the initialization of
> an unused variable? it struck me at the time that it was
> much more my fault!)

It is perfectly fine to optimize away the initialization,
and indeed the variable itself.

But what would possibly make you think (RM reference
please) that it was OK to eliminate the call.

Optimizations, except where specifically permitted by 11.6,
must not affect the external behavior!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Unreferenced lock variables

[Jean-Pierre Rosen]

Robert Dewar a �crit dans le message
<7esrmv$k1n$1@nnrp1.dejanews.com>...
>With regard to initialization and finalization, the ARG
>just agreed (unwisely if you ask me!) to allow a compiler
>to optimize away initialization and finalization for an
>otherwise unreferenced variable. GNAT does not take
>advantage of this, but it means that to be compeltely
>portable, you need to put in a dummy reference to the
>variable.
Only for non-limited controlled types. If you don't use the variable,
make the type limited. It makes no difference, and the AI ensures that
Initialization/Finalization is NOT optimized away.
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Unreferenced lock variables

[Simon Wright]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

> Only for non-limited controlled types. If you don't use the variable,
> make the type limited. It makes no difference, and the AI ensures that
> Initialization/Finalization is NOT optimized away.

Strictly, I suppose, the AI only adds weight to a complaint to your
compiler vendor when he's got it wrong ..

Re: Unreferenced lock variables

[Robert Dewar]

In article <7eta1t$pp0$2@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> Only for non-limited controlled types. If you don't use
> the variable, make the type limited. It makes no
> difference, and the AI ensures that
> Initialization/Finalization is NOT optimized away.

I still consider this to be a FAR too extensive
implementation dependency, it means that programs
that work fine on one compiler malfunction in the
most odd way on another, because locks are simply
mysteriously missing.

As I noted, GNAT has NO intention of taking advantage
of this optimization freedom, which seems extremely
marginal in any case.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Unreferenced lock variables

[Robert Dewar]

In article <7eta1t$pp0$2@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> Only for non-limited controlled types. If you don't use
> the variable, make the type limited. It makes no
> difference, and the AI ensures that
> Initialization/Finalization is NOT optimized away.

Note that a quite natural style is to declare such a
variable with an initialization expression that does
something, and that will lead you naturally to a
non-limited type, which is the case that can cause
you trouble, but perhaps not immediately if your
compiler feels that it should NOT optimize this away.

I hope at least that compilers that perform this
unwise optimization will warn users that they are
doing it.

Warning: I have removed the Initialization/Finalization
calls for the object "Critical_Lock_Do_Not_Remove".

Or some such message ....

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Unreferenced lock variables

[Tom Moran]

>With regard to initialization and finalization, the ARG
>just agreed (unwisely if you ask me!) to allow a compiler
>to optimize away initialization and finalization for an
>otherwise unreferenced variable.
It seems such a bad idea - what arguments led them to this decision?

Re: Unreferenced lock variables

[Robert Dewar]

In article <3713b417.22324981@news.pacbell.net>,
> It seems such a bad idea - what arguments led them to
> this decision?

There are good arguments on both sides. See the AI (this
is not secret information :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Unreferenced lock variables

[Tom Moran]

> See the AI
Which one.  There are quite a few to search through.

Re: Unreferenced lock variables

[Robert Dewar]

In article <371658a7.19974365@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> > See the AI
> Which one.  There are quite a few to search through.

I don't know, it is you who wants to read it, so I figure
you get to do the search :-) :-)

(but maybe Tuck or Bob or someone else can lay their
hands on the number more easily ...)
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Unreferenced lock variables

[Tom Moran]

I found AI-00147, which as far as I can see gives no significant
arguments *for* eliminating in the non-limited case, except "doing
Initialization/Finalization is expensive".  It seems to that either
the programmer intended the object to be declared, even though he
doesn't use it, or it was a mistake on his part and a warning should
be generated (as for unused Integer, Boolean, and other non-controlled
types).  So possibly such a warning in the non-limited case would be
reasonable, but simply assuming the programmer did not really intend
to declare the controlled object, is hubris.
  Or is there another AI that I missed? 

Re: Unreferenced lock variables

[Tucker Taft]

Tom Moran wrote:
> 
> I found AI-00147, which as far as I can see gives no significant
> arguments *for* eliminating in the non-limited case, except "doing
> Initialization/Finalization is expensive".  It seems to that either
> the programmer intended the object to be declared, even though he
> doesn't use it, or it was a mistake on his part and a warning should
> be generated (as for unused Integer, Boolean, and other non-controlled
> types).  So possibly such a warning in the non-limited case would be
> reasonable, but simply assuming the programmer did not really intend
> to declare the controlled object, is hubris.
>   Or is there another AI that I missed?

Here is a motivating example:

    X : My_Controlled_Type;
  begin
    ...
    X := Y;
    ...
  end;

Presuming My_Controlled_Type has a user-defined Initialize,
Finalize, and Adjust, the sequence of implicit calls currently 
required is:
    Initialize(X);
     ...
    Finalize(X)
    <copy Y to X>
    Adjust(X)
    ...
    Finalize(X)

The goal is to eliminate the first Initialize/Finalize pair.
Doing this requires some care, because if an exception is raised
before the assignment of Y to X, you don't want X to be finalized
if it has never been initialized.

Perhaps one way to resolve the concern is to give the permission
to remove an Initialize/Finalize pair only if there is an assignment
(presumably with Adjust) to the object, essentially allowing
the creation of the object to be deferred until the first assignment,
thereby bypassing the need for any default initialization.

-Tuck
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Unreferenced lock variables

[Tom Moran]

What we really need is a way to speak of an 'extended object', eg, a
linked list of objects or an attached set of peripheral devices, etc..
The only way now is to make controlled components and then have them
do list walking or hardware setup/takedown, or whatever.  The abstract
"object" in those cases is something much larger than a single chunk
of data.

Re: Unreferenced lock variables

[Tom Moran]

>permission
>to remove an Initialize/Finalize pair only if there is an assignment
Ah, so the complete removal of the (seemingly) unused control type
declaration is a consequence of being able to optimize the case where
it is in fact used (later)? 
> Initialize(X);
>     ...
>    Finalize(X)
>    <copy Y to X>
What happens if the Initialize or Finalize of X, (which will be
optimized away) modifies Y?  Or is that illegal?

Re: Unreferenced lock variables

[Tucker Taft]

Tom Moran (tmoran@bix.com) wrote:

: >permission
: >to remove an Initialize/Finalize pair only if there is an assignment

: Ah, so the complete removal of the (seemingly) unused control type
: declaration is a consequence of being able to optimize the case where
: it is in fact used (later)? 
: > Initialize(X);
: >     ...
: >    Finalize(X)
: >    <copy Y to X>
: What happens if the Initialize or Finalize of X, (which will be
: optimized away) modifies Y?  Or is that illegal?

It is certainly not "illegal," but if this rule is adopted, it would
probably be unwise ;-).  

The point of rules like this is to allow controlled objects to be treated 
largely like "normal" variables w.r.t. dead load/store removal, value 
propagation, etc.  

The rule would be analogous to the rule about functions in declared-pure 
packages.  They need not be called under certain circumstances, independent 
of whether they do or do not have "interesting" side-effects.
It is the programmer's responsibility to create operations that
are consistent with the possibility that they might be "optimized away."

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Unreferenced lock variables

[Tom Moran]

>>With regard to initialization and finalization, the ARG
>>just agreed (unwisely if you ask me!) to allow a compiler
>>to optimize away initialization and finalization for an
>>otherwise unreferenced variable.
>It seems such a bad idea - what arguments led them to this decision?
Randy Brukardt was kind enough to educate me on some of the points
here, including
procedure Something(P : in integer) is
  Unused : integer := P/0;
begin ...
which can legally have Unused eliminated and thus the divide by zero
eliminated.  That certainly provides an analogous precedent for
eliminating the controlled Initialize/Finalize.  So with 'limited'
still available when you really gotta have Initialize/Finalize, I
guess it's not so unreasonable to eliminate the controlled object (in
the non-limited) case after all.

Re: Unreferenced lock variables

[Robert Dewar]

In article <3718268c.48395643@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> Randy Brukardt was kind enough to educate me on some of
> the points here, including

> procedure Something(P : in integer) is
>   Unused : integer := P/0;
> begin ...

> which can legally have Unused eliminated and thus the
> divide by zero eliminated.  That certainly provides an
> analogous precedent for eliminating the controlled
> Initialize/Finalize.

This is a bad analogy. Yes, I know that some of the ARG
members used this to justify the position taken, but the
reasoning is faulty.

In the case of built-in language checks, the idea is to
prevent the program from doing something bad. In other
words a divide by zero is an error in your program, and
if it happens you want to know about it. We decided early
on in Ada 83 that it was OK to eliminate such exceptions
if the situation leading to the error can be safely
eliminated. There are three reasons here:

1) We really don't want the nice checking in Ada to damage
code generation unnecessarily. Programmers want to know if
a real error occurs, but they do not need to know EXACTLY
where a constraint error is raised, or to know about a
CE that in fact was not raised at all for good and sound
reasons.

2) If we eliminate the divide in a case like this, we
eliminate the error. So the idea of run time checks, to
check for errors is not violated by this optimization.

3) A correct program does not raise exceptions like this
anyway (if you use divide by zero as a normal case control
structure, you should be drummed out of the Ada community!)
This means that correct programs are not affected by these
kinds of optimizations.

Now the initialize/finalize case is TOTALLY different. None
of the above considerations applies. In fact this is the
thin end of a very dangerous wedge.

Here for the first time we have well defined behavior from
a program, which we know that existing programs sometimes
use for good reasons, and we suddenly introduce a new rule
which allows the optimizer to optionally change the
behavior of the program in a fundamental way that is
incompatible with what is in the RM.

This is not what I call an optimization!

Yes, there have been discussions of possible optimizations
in the case of temporaries created by the compiler, but
such temporaries are in some sense an artifact of the
implementation anyway. Here we are talking about a declared
variable, and it is 100% clear that the current RM requires
the initialize and finalize call.

Why the thin end of the wedge?

Because next someone will say

  X : Integer := Function_With_Side_Effects;

is allowed NOT to call the function if X is unused, and
away we go down the slippery slope.

A couple of further points here.

GNAT will most certainly NOT take advantage of this
optimization, it seems a bad idea.

If you have no user defined initialization routine, and
a finalization routine whose only purpose is to release
storage, then you can use the GNAT pragma

  pragma Finalize_Storage_Only (subtype_NAME);

which tells the compiler to omit the Finalize call if it
is not needed, e.g. at the outer level, or all the time in
a Java environment.

Such pragmas that control the behavior of the compiler are
legitimate, and I would have no objection to a pragma
saying

  pragma Omit_Initialize_Finalize_For_Unused;

but to allow this optimization without such a pragma is
to me a language change justified only by the hope that
an "optimization" will be significantly worth while (only
a hope, no quantitative data of any kind is available!)

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Unreferenced lock variables

[Tom Moran]

>> procedure Something(P : in integer) is
>>   Unused : integer := P/0;
>> begin ...

>> which can legally have Unused eliminated and thus the
>> divide by zero eliminated.  That certainly provides an
>> analogous precedent for eliminating the controlled
>> Initialize/Finalize.

>This is a bad analogy.
How about
type Back_Track_Type is array(integer range <>) of integer; 
function Big_Calculation(Distance:in integer; Time:in integer; ...)
return Back_Track_Type is  
   Speed : integer := Distance/Time;
   Where_it_was : Back_Track_Type(1 .. Time);
begin
   -- various calculations, some of which assume that the speed is
non-zero, but none of which actually mentions the variable "Speed"
  Granted, this would be poor programming, but the Distance/Time
calculation would give a divide by zero at the start of
Big_Calculation, while optimizing it away might result in erroneous
calculations that wouldn't show up till much later, in some other
place when it is surprisingly discovered that the back_track array
returned from the function was in fact null.  It seems to me that's a
closer analogy in terms of the difference in program behavior.

Re: Unreferenced lock variables

[Robert Dewar]

In article <371cadb6.1137490@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> It seems to me that's a
> closer analogy in terms of the difference in program
> behavior.

I disagree strongly, but I have nothing further to add
from my previous message, which covers this situation
completely.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own