[Mpi-forum] Comment on Fortran WG5 ballot N1846

[N.M. Maclaren]

On Apr 12 2011, Bill Long wrote:
>>
>Option 4:  (Which you are free to dismiss, but you did ask...)
>
>Another option, which could be made reliable, but is politically 
>radical, would be to make specific requirements on the compiler vendor 
>and user, rather than try to modify or leverage  the Fortran standard. 
>  This is the approach used by OpenMP which makes numerous rules that a 
>compiler must obey to claim that it supports the OpenMP standard.

Yes.  Actually, I don't think that the options really differ all that
much, and there never was any alternative to requiring support from
the vendor.  Given that, Fortran's and MPI's rules are so nearly
identical that I can't find a meaningful difference - with the proviso
that (as Bill mentioned), Fortran arrays are first-class objects and
not just a collection of elements and so a property of an array applies
to the whole of the array.

Nothing in that stops non-overlapping parts of an array from being used
for different purposes at the same time, of course.

I remarked some time ago that ASYNCHRONOUS defines precisely the required
semantics for non-blocking transfers, if they were implemented using
Fortran asynchronous I/O and a processor-dependent socket option in the
OPEN statement!  But that's a constraint on the programmer only.
Constraining vendors is trickier, especially when it is to facilities
outside the standard.

Realistically, in both Fortran and C, compilers will vary immensely in
the proportion of MPI that they are compatible with.  Non-blocking is
fairly easy, but passive one-sided is beyond hope in either the C or
Fortran standards.  That simply has to be left as a vendor option.


Regards,
Nick Maclaren.