[MPI3 Fortran] Nonblocking MPI and Fortran temporary memory modifications

[Rasmussen, Craig E]

I don't want to debate this further as a vote on the issue was already taken at J3 on the use of the ASYNCHRONOUS attribute in this context.

-craig

On Mar 28, 2011, at 11:13 AM, Dan Nagle wrote:

> Hi,
> 
> I think I understand the problem.
> 
> I don't think you understand the objection to your solution.
> 
> Expecting one processor to generate code based on what another processor *might* do
> is a non-starter.
> 
> The whole "MPI is just like I/O" view is wrong.  The devil is in the details.
> 
> If you want to debate this further, I suggest we take it offline.
> 
> On Mar 28, 2011, at 13:05 , Rasmussen, Craig E wrote:
> 
>> Dan,
>> 
>> Perhaps I haven't sufficiently explained what we need to do in MPI3, as I'm not sure what you are trying to convey with restrictions on programs versus restrictions on processors.
>> 
>> The ASYNCHRONOUS attribute has a certain semantic meaning in the context of a valid program.  For MPI3 we want the semantics of ASYNCHRONOUS to include that a variable with the ASYCHRONOUS attribute may be subject to asynchronous activity, not just asynchronous input/output (as currently stated in 5.3.4).  Rolf's worry (at least it should be) is that the MPI3 standard can't point to a place in the Fortran standard that says a compiler/processor in not conforming if it does not also take into account that a variable with the ASYNCHRONOUS attribute may be subject to asynchronous activity and thus restrict code motion and other optimizations for the variable within the scope that the ASYNCHRONOUS attribute is active.
>> 
>> -craig
>> 
>> On Mar 28, 2011, at 10:46 AM, Dan Nagle wrote:
>> 
>>> Hello,
>>> 
>>> On Mar 28, 2011, at 12:14 , Rasmussen, Craig E wrote:
>>>> 
>>>> So the question is not about whether a compiler implements ASYNCHRONOUS I/O but whether it respects the ASYNCHRONOUS semantics.
>>> 
>>> I think the question is whether a processor respects
>>> its own asynchronous semantics.
>>> 
>>> I would be perverse to require processor A to respect
>>> what processor B (C, D, E, ...) _might_ do in some,
>>> perhaps very rare, circumstances.
>>> 
>>> Annex A is four pages.  The Fortran standard is a set
>>> of restrictions on programs, not processors, unless otherwise
>>> explicitly stated.
>>> 
>>> -- 
>>> Cheers!
>>> 
>>> Dan Nagle
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> mpi3-fortran mailing list
>>> mpi3-fortran at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>> 
>> 
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
> 
> -- 
> Cheers!
> 
> Dan Nagle
> 
> 
> 
> 
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran