[mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates

Pavan Balaji balaji at mcs.anl.gov
Tue Aug 27 13:44:03 CDT 2013


Hi Keith,

Did you see Jim's email?  He raised a good point that even with 
OpenSHMEM this is undefined.  You need to use a function call to make it 
have defined behavior.  So is it still true that OpenSHMEM cannot be 
implemented on top of MPI?

  -- Pavan

On 08/27/2013 01:38 PM, Underwood, Keith D wrote:
> Yes, I want it to be defined.  I don’t think that version of defined is
> a problem.  The definition just has to happen in terms of what is in
> memory and say “an implementation might reorder your loads in fun and
> exciting ways” ;-)  This is pretty close to just saying the public and
> private window are the same.
>
> Undefined in the way MPI phrases it allows a unified where it is
> impossible to use it without the MPI_WIN_SYNC.  That isn’t ok.
>
> *From:*mpiwg-rma [mailto:mpiwg-rma-bounces at lists.mpi-forum.org] *On
> Behalf Of *Jeff Hammond
> *Sent:* Tuesday, August 27, 2013 2:31 PM
> *To:* Pavan Balaji
> *Cc:* MPI Forum
> *Subject:* Re: [mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED
> model updates
>
> Keith's definition is not a definition in the sense of MPI semantics
> being "defined".  What he is proposing is to be pedantic about the fact
> that the user may want to rely upon implementation-defined behavior to
> realize the best performance or to avoid changing existing SHMEM code.
>
> The MPI standard isn't defining something if it's not explicitly defined
> in the standard.  Therefore, it must be called "undefined".  If you or
> Keith want to call this "defined" behavior, then I'm going to insist
> that it be defined in the usual sense, which means the text of the
> standard will enumerate the behavior of MPI in an
> architecture-independent way.
>
> Jeff
>
> On Tue, Aug 27, 2013 at 11:19 AM, Pavan Balaji <balaji at mcs.anl.gov
> <mailto:balaji at mcs.anl.gov>> wrote:
>
>
> On 08/27/2013 12:57 PM, Jeff Hammond wrote:
>
> The MPI standard will not define by what mechanism the SHMEM
> implementation will establish the necessary consistency.  This is what I
> mean by undefined = implementation-defined.  I do not think that Keith
> is proposing to enumerate all processor memory models and the
> appropriate fences required to achieve the affect of win_sync but at
> lower cost.  Thus, it is the implementation - or perhaps more
> accurately, the platform on which the implementation resides - that will
> define these semantics.
>
> Here's what I understood from Keith --
>
> He wants a statement in the standard that says the application can do
> platform-specific memory consistency to synchronize the public and
> private windows in UNIFIED.
>
> I do agree that that's a very flimsy statement and doesn't really mean
> much.  But I'm calling it a definition, while I think you are saying
> that it's pretty much undefined.
>
> I like leaving it totally undefined better than the above "definition".
>
>
>
>   -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
>
>
>
> --
> Jeff Hammond
> jeff.science at gmail.com <mailto:jeff.science at gmail.com>
>

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji



More information about the mpiwg-rma mailing list