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

[Jeff Hammond]

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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130827/21f94551/attachment-0001.html>