[MPI3 Fortran] [Fwd: Library-based ASYNCHRONOUS I/O and SYNC MEMORY]

[Iain Bason]

On Sep 9, 2008, at 3:08 PM, Aleksandar Donev wrote:

> On Tuesday 09 September 2008 11:48, Iain Bason wrote:
>
>> If I understand your proposal, it requires adding SYNC MEMORY
>> statements wherever one calls MPI_IRECV or MPI_WAIT.  What are the
>> semantics if the user does not do that?
> The program is not standard conforming---it doesn't have semantics :-)

That wasn't clear to me from the proposal.  In particular, I didn't  
see anything that specified how "a means not specified by the program"  
relates to segments.

>> Of course, using the syntactic sugar you propose (having a SYNC
>> attribute for procedures) is pretty similar to what I proposed.  The
>> difference is the spelling and that your proposal restricts the  
>> effect
>> to variables with the ASYNCHRONOUS attribute.
> Yes, that's one important difference. Another is that my proposal  
> uses already
> defined semantics of SYNC MEMORY and the concept of execution  
> segments. Sorry
> I cannot describe that fully here---John Reid has written about it  
> and have I
> elsewhere...I can point you to it if you are interested. I find this
> semantics appropriate, well-defined, and it is already in the F2008  
> standard.

Yes, I've read section 8.5 of the draft standard.  (I haven't read it  
closely enough to decide whether I agree that the semantics are well  
defined, but for now I'll assume they are.)

> Now, granted, I am biased, since John, Bill and I designed the segment
> model...
>
>> Meaning that the compiler should do what?  Treat any variable with  
>> the
>> ASYNCHRONOUS attribute as if it has the VOLATILE attribute?
> No--the essential and important difference with VOLATILE is clearly  
> spelled
> out in my proposal, in the very opening para!
>
> "The VOLATILE attribute
> may be used to signal to the compiler that a variable may be modified
> asynchronously by an external mechanism, however, this disables
> all optimizations involving the variable, which is not needed..."

OK, that describes what it doesn't mean.  So what does it mean?   
Should an ASYNCHRONOUS variable be treated just like any non-VOLATILE  
variable within the segment?  [I think you say later on that it should.]

To me, the language in the F2008 standard does not imply that "the  
asynchronous modification occurs for a certain *duration* of Fortran  
execution sequence".  (It is of course consistent with that execution  
model, since that is presumably what should be implemented behind the  
scenes.  But the language itself, from a light reading, seems to  
merely place restrictions on how variables can be used when segments  
are unordered.  Are you just saying that the MPI standard should  
essentially incorporate those restrictions implicitly?  Or is there  
some deeper semantic implication to SYNC MEMORY that I've overlooked?)

>> If the effect is to inhibit optimizations for that duration,
>> then we need to know which optimizations will be inhibited.
> The only optimization inhibited is motion across the SYNC MEMORY  
> boundaries.
> The rest is restrictions on the programmer and mere explanations of  
> the
> semantics (i.e., permission to modify the variables outside of the  
> program
> and a requirement to specify the attribute if needed).

OK, that's good enough.

I do think, however, that having a SYNC attribute for a procedure  
ought to be considered more than syntactic sugar.  In particular, I  
think that any procedure that calls another procedure with the SYNC  
attribute should itself be required to have the SYNC attribute.

> BTW
>> Yes, we need a mechanism to avoid copy in/out.  It need not be the
>> same mechanism.
> The ASYNCHRONOUS attribute solves that problem (to some extent).

You mean applying the ASYNCHRONOUS attribute to a dummy variable in an  
interface?  Yes, that seems as though it would work.

Iain