(j3.2006) an alternative to Aleks' asynchronous proposal

[Lionel, Steve]

Aleks wrote:
> > The persistent subroutine
> > is allowed to access, define, reference, undefined,
> > or anything else to arguments that it maintains
> > (or acquires from another persistent subroutine)
> > an association to.
> The persistent subroutine returned and is no longer executing. So it
> cannot do
> anything. Allowing variables to be modifed externally (asynchronously)
> at
> will, without a special attribute, is IMO a big mistake likely to lead
> to
> conflicts between compilers (who think they are optimizing), and users
> (who
> think they know what the compiler is optimizing).

It is not true that the subroutine "is no longer executing".  The
subroutine may (and in this case has) started an asynchronous activity
that continues execution, potentially, after the call returns. Or, the
argument association may be remembered for implicit use in a later call
- the net effect is the same.

However, I am uneasy about Dick's proposal - especially as there is no
indication to the compiler (or reader of the code) as to when such
persistence ends.  The practical effect of this is that a compiler will
simply have to assume that any variables passed in an actual argument
list to a PERSISTENT routine are effectively volatile (in the C sense)
and can change or be referenced in ways invisible to the compiler, from
the first call to the end of the current procedure (and then?)

Furthermore, any procedure in the application that calls a PERSISTENT
procedure will itself need to have the PERSISTENT attribute, otherwise
callers to it may pass variables and try to access them upon return when
they are still "in play". Of course, the same can be said of variables
with the VOLATILE or ASYNCHRONOUS attribute, though in the case of
ASYNCHRONOUS as it stands today, the semantics are well-defined.

I tend to lean towards Aleks' proposal, at least as far as the use of
ASYNCHRONOUS goes, as it tells the compiler which variables are "in
play" (not all arguments to an MPI call are).  What I'm less comfortable
with is the appropriation of SYNC MEMORY, though I understand completely
why Aleks chose this, and any alternative would just be a different way
of saying the same thing, so I have nothing better to propose, unless we
are to add a block construct with syntax listing the variables that
should be considered asynchronous in that block.  

Should a statement be added saying that there is an implicit memory
synchronization point at the "return" point for the current procedure?
The programmer would be responsible to ensure that this was actually the
case (with an MPI_WAIT call or some such.)  Some programmers might find
this too limiting.

Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH