Releasing Aliased Variables

Releasing Aliased Variables

[Byron Kauffman]

I'm having a problem understanding what defining a variable as aliased
does. Is there a problem with releasing an aliased pointer? Can or
should you even alias a pointer?

I'm using  DirectSound on NT using WinAPI bindings provided by Aonix to
play sounds with my application. To make a long story short, the
procedure you follow is to create a directsound object, create a primary
buffer, and create secondary buffers with all your sounds. Then, when
you're about to shut down the app, you call WinAPI release methods to
release the secondary buffers, the primary buffer, and the directsound
object, in that order. If anything happens to screw up the shutdown and
the objects aren't released, it's only a matter of time before you have
to reboot to reclaim the memory.

I'm declaring all of the directsound objects as aliased, which solved a
problem I was having creating the objects ( it looked like some very
large buffers were being created on the stack). What's happening now is
that the release procedure is bombing down in the Windows code, so
control never returns.

Re: Releasing Aliased Variables

[tmoran]

>release the secondary buffers, the primary buffer, and the directsound
>object, in that order.
> ...
>that the release procedure is bombing down in the Windows code, so
  At which release does it crash?
>I'm declaring all of the directsound objects as aliased, which solved a
  Declaring X aliased says "take care.  There may be pointers to
this, so just looking at all mentions of "X" may miss some activity
on P.all where P.all is in fact X"  Perhaps you've already released
a buffer through a pointer to it, and now you're trying to release
it directly?

Re: Releasing Aliased Variables

[Robert A Duff]

Byron Kauffman <byronbkauffman@netscape.net> writes:

> I'm having a problem understanding what defining a variable as aliased
> does. Is there a problem with releasing an aliased pointer? Can or
> should you even alias a pointer?

If you declare X to be aliased, then you may say X'Access or
X'Unchecked_Access to create a pointer to it.  This makes the code
easier to understand, because you know that such pointers might exist.

In code-generation terms, it causes X to allocated at an addressable
location (eg, not in a register).  It is unlikely that "aliased"
controls whether X is allocated on the stack versus the heap (but of
course compilers can do what they like).

If Y = X'Access, then make sure you never call Unchecked_Deallocation on
Y.

> I'm declaring all of the directsound objects as aliased, which solved a
> problem I was having creating the objects ( it looked like some very
> large buffers were being created on the stack). What's happening now is
> that the release procedure is bombing down in the Windows code, so
> control never returns.

Sounds like some sort of dangling-pointer problem.  Declaring things
aliased wouldn't directly cause that, but deallocating things at the
wrong time, or twice, or returning X'Unchecked_Access where X is local
could all cause that sort of trouble.

- Bob

Re: Releasing Aliased Variables

[Florian Weimer]

Robert A Duff <bobduff@world.std.com> writes:

> In code-generation terms, it causes X to allocated at an addressable
> location (eg, not in a register).  It is unlikely that "aliased"
> controls whether X is allocated on the stack versus the heap (but of
> course compilers can do what they like).

Some time ago, there was a thread in which someone explained (I think
Robert Dewar) that 'aliased' does not provide any help to the compiler
regarding alias detection, register allocation etc. because the
compiler has to be able to determine this kind of information anyway
if an Address attribute is used.

So in code-generation terms, 'aliased' is a no-op.

Re: Releasing Aliased Variables

[Pat Rogers]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87bsrcs8a3.fsf@deneb.enyo.de...
> Robert A Duff <bobduff@world.std.com> writes:
>
> > In code-generation terms, it causes X to allocated at an addressable
> > location (eg, not in a register).  It is unlikely that "aliased"
> > controls whether X is allocated on the stack versus the heap (but of
> > course compilers can do what they like).
>
> Some time ago, there was a thread in which someone explained (I think
> Robert Dewar) that 'aliased' does not provide any help to the compiler
> regarding alias detection, register allocation etc. because the
> compiler has to be able to determine this kind of information anyway
> if an Address attribute is used.

Did you mean "Access" instead of "Address"?

> So in code-generation terms, 'aliased' is a no-op.

Unless that part of the code generation is deferred to link time (which
happens for other things), I don't see how that can cover the case of
separately compiled code -- one containing the declaration and the other
containing the corresponding 'Access.

Re: Releasing Aliased Variables

[Florian Weimer]

"Pat Rogers" <progers@NOclasswideSPAM.com> writes:

> > Some time ago, there was a thread in which someone explained (I think
> > Robert Dewar) that 'aliased' does not provide any help to the compiler
> > regarding alias detection, register allocation etc. because the
> > compiler has to be able to determine this kind of information anyway
> > if an Address attribute is used.
> 
> Did you mean "Access" instead of "Address"?

No, I didn't.  That's the point.

Re: Releasing Aliased Variables

[Tucker Taft]

Florian Weimer wrote:
> 
> Robert A Duff <bobduff@world.std.com> writes:
> 
> > In code-generation terms, it causes X to allocated at an addressable
> > location (eg, not in a register).  It is unlikely that "aliased"
> > controls whether X is allocated on the stack versus the heap (but of
> > course compilers can do what they like).
> 
> Some time ago, there was a thread in which someone explained (I think
> Robert Dewar) that 'aliased' does not provide any help to the compiler
> regarding alias detection, register allocation etc. because the
> compiler has to be able to determine this kind of information anyway
> if an Address attribute is used.
> 
> So in code-generation terms, 'aliased' is a no-op.

The rules on 'Address are pretty tricky, and the compiler has
to make several assumptions about "normal" use of 'Address to
deal with it reasonably.  In particular, it generally assumes that there
is no use of 'Address if it can't "see" the use of 'Address.

Furthermore, unless an object is marked aliased 
(or the object is of a by-ref type or had its address
specified), there is no requirement for 'Address to work at all.
See RM95 13.3(16).

On the other hand, "aliased" has very well defined semantics, and
compilers that do any sort of optimization treat aliased objects
quite differently than non-aliased objects.  Any store through a
pointer of a general access type which might legitimately be pointing
to the aliased object is presumed to kill the aliased object.  
Compilers are not that pessimistic about other objects that might
somewhere have had their address taken (perhaps because their address
was "captured" by calling a function which took 'Address of a
formal and then stored the value in some global pointer).

So *do* use "aliased" if you want reliable results... 

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Burlington, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/services/ebusiness_applications.html)

Re: Releasing Aliased Variables

[Robert A Duff]

Florian Weimer <fw@deneb.enyo.de> writes:

> Some time ago, there was a thread in which someone explained (I think
> Robert Dewar) that 'aliased' does not provide any help to the compiler
> regarding alias detection, register allocation etc. because the
> compiler has to be able to determine this kind of information anyway
> if an Address attribute is used.

Well, you're "supposed" to use "aliased" if you're going to use
'Address.  But of course Ada 83 code doesn't do that, and Ada 95 code
only does it if the programmer knows this obscure fact.  So in practice,
Robert is correct, at least for local variables, where the compiler has
a hope of tracking down all references to 'Address.

For 'Access, you *must* use aliased.  For 'Address, you *should* -- if
you don't, the RM says your code might not work.  But it will *probably*
work in most cases, because compiler writers want Ada 83 code to work in
Ada 95!

> So in code-generation terms, 'aliased' is a no-op.

Not entirely.

- Bob

Re: Using COM Interfaces (was: Releasing Aliased Variables)

[Byron Kauffman]

Thanks for the discussion. Now I might narrow things down. The bindings I'm
using are to the DirectSound COM interfaces. I'm declaring pointers in the
package body that get passed into DS methods to create objects, after which
they point to the created objects. My understanding now is that those
pointers don't have to be aliased. Any guesses where the objects are
created?

On the other hand, some of the methods defined for the DS objects pass
pointers to pointers. Would it be a good idea to alias them?

I hate Microsoft.

Robert A Duff wrote:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
> > Some time ago, there was a thread in which someone explained (I think
> > Robert Dewar) that 'aliased' does not provide any help to the compiler
> > regarding alias detection, register allocation etc. because the
> > compiler has to be able to determine this kind of information anyway
> > if an Address attribute is used.
>
> Well, you're "supposed" to use "aliased" if you're going to use
> 'Address.  But of course Ada 83 code doesn't do that, and Ada 95 code
> only does it if the programmer knows this obscure fact.  So in practice,
> Robert is correct, at least for local variables, where the compiler has
> a hope of tracking down all references to 'Address.
>
> For 'Access, you *must* use aliased.  For 'Address, you *should* -- if
> you don't, the RM says your code might not work.  But it will *probably*
> work in most cases, because compiler writers want Ada 83 code to work in
> Ada 95!
>
> > So in code-generation terms, 'aliased' is a no-op.
>
> Not entirely.
>
> - Bob

Re: Using COM Interfaces (was: Releasing Aliased Variables)

[Robert A Duff]

Byron Kauffman <byronbkauffman@netscape.net> writes:

> On the other hand, some of the methods defined for the DS objects pass
> pointers to pointers. Would it be a good idea to alias them?

I don't know the answer to your main question, but I can tell you the
Ada rule: if you want to say X'Access, then you must declare X to be
aliased.  If you want to say X'Address, then you *should* declare X to
be aliased.  It is irrelevant whether or not X is itself also a
pointer.

X'Unchecked_Access is like X'Access, except it allows the creation of
dangling pointers.

If you do not want to use any of these three attributes on X, then you
should not declare X to be aliased.

- Bob

Re: Using COM Interfaces (was: Releasing Aliased Variables)

[tmoran]

>I'm declaring pointers in the
>package body that get passed into DS methods to create objects, after which
>they point to the created objects.
>...
>Any guesses where the objects are created?
  Do you mean you are passing null pointers in and getting actual pointers
out?  So the C calling sequence must include something like
  &buffer_pointer
and you are actually passing the locations of pointers in, and letting
the DS methods put values into those pointers.  If that's the case, then
the storage allocation is occurring in the DS methods, not in the
Ada part of the program, and it would probably be wise to make an
appropriate DS call to ask it to free the space, rather than trying
to do an Unchecked_Deallocation in the Ada part.  (It may be that
the DS system wants to do some extra housekeeping when you free a
buffer, for instance.)

>My understanding now is that those pointers don't have to be aliased.
  It's not Pointers that need to be aliased, but rather things pointed
At.  Of course you can point At a pointer as well as pointing At an
integer, in which case that pointer should indeed be aliased.  If
you are passing things'access in to DS methods, then, since they are
used with 'access, they need to be aliased.  But if you are declaring
that DS parameter as "in out" or "out", then you don't need the 'access,
which means you don't need the "aliased".

Re: Releasing Aliased Variables

[Richard Kenner]

In article <87bsrcs8a3.fsf@deneb.enyo.de> Florian Weimer <fw@deneb.enyo.de> writes:
>Some time ago, there was a thread in which someone explained (I think
>Robert Dewar) that 'aliased' does not provide any help to the compiler
>regarding alias detection, register allocation etc. because the
>compiler has to be able to determine this kind of information anyway
>if an Address attribute is used.
>
>So in code-generation terms, 'aliased' is a no-op.

That's not completely true.  It has at least two effects:

(1) An aliased component of an aggregate must be on the same alignment
boundary as its type, which affects packing in records and allowable
record rep clauses.

(2) If you have a de-reference through an access type for some type
and you have a field of an aggregate that is of that type, you know
that the reference *cannot* be to that field.

Re: Releasing Aliased Variables

[Florian Weimer]

Byron Kauffman <byronbkauffman@netscape.net> writes:

> I'm having a problem understanding what defining a variable as aliased
> does. Is there a problem with releasing an aliased pointer? Can or
> should you even alias a pointer?

What is an 'aliased pointer'?  Aliased objects are required if you
want to obtain an access value (using the Access attribute).  They
don't need to be deallocated themselves, in contrast to objects
created by an allocator.