[mpiwg-rma] Memory model and source code portability

[Rolf Rabenseifner]

> If you agree with Boehm’s article in the strongest form, then you can
> maintain source code portability by avoiding the use of features
> that are not well defined in the source language - i.e., the use of
> shared memory. 

Bill, please read my example. It is not using shared memory.
If we agree with Boehm's article, then it has direct implication
to normal nonblocking pt-to-pt as soon as the MPI library
uses internally a progress thread. This should be allowed.
Or in other words, not only Fortran is a special case.
With C, we Need not to talk to the C standardization body.
Similar to Fortran TS29113, the C standardization body
already did what MPI needs.

As soon as we say, MPI has a C binding, and allow nonblocking pt-to-pt
and allow parallel progress engines, we should say that this 
requires the C11 memory model, i.e., the user must not modify 
ist optimization in a way that the C11 Memory model is no longer
guaranteed.

MPI provides a C binding, C does not provide an MPI binding.
Therefore, it is our job.
Otherwise MPI does not provide source code portability.

Rolf

  

----- Original Message -----
> From: "William Gropp" <wgropp at illinois.edu>
> To: "MPI WG Remote Memory Access working group" <mpiwg-rma at lists.mpi-forum.org>
> Sent: Tuesday, September 30, 2014 6:43:39 PM
> Subject: Re: [mpiwg-rma] Memory model and source code portability
> 
> 
> Not at all.  It just isn’t our place to talk about other standards.
>  Fortran was a slightly different case because of the discussions
> between members of the MPI Forum and the Fortran standards
> committee.  We don’t have that option with C, and I don’t think we
> ever will, since MPI programs are not an important part of the use
> of C.
> 
> 
> If you agree with Boehm’s article in the strongest form, then you can
> maintain source code portability by avoiding the use of features
> that are not well defined in the source language - i.e., the use of
> shared memory.  The current straw vote addresses something at (a) is
> within the definitions under control of the MPI Forum and (b) allows
> users that are willing to do what virtually everyone currently using
> threads and shared memory does - rely on the compiler and processing
> environment to implement something other than the standard language.
>  But that latter case does not belong in a standard document.
> 
> 
> Bill
> 
> 
> 
> On Sep 30, 2014, at 11:23 AM, Rolf Rabenseifner <
> rabenseifner at hlrs.de > wrote:
> 
> 
> For me it looks like that you give up with the important goal
> that the MPI standard should provide source code portability.
> 
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)