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

[Jeff Hammond]

I thought OpenSHMEM 1.0 was required to be SGI-SHMEM with minor
corrections for legal reasons but that future specs can be improved to
behave in a self-consistent way, have a finalize routine, etc.

We should consider writing something for IWOSH if we think OpenSHMEM
needs to be changed to work over MPI-3. Now is a good time to figure
out the give and take between the two specs.

Jeff

Sent from my iPhone

On Aug 27, 2013, at 6:20 PM, "Underwood, Keith D"
<keith.d.underwood at intel.com> wrote:

>>> I'm having trouble with the exact phrasing, but my thought is that we
>>> should have an advice to users that says 1) while the view of memory
>>> is consistent in UNIFIED, other artifacts (such as processor or memory
>>> controller reordering) can result in unexpected behavior 2)
>>> MPI_WIN_SYNC may be used to provide stronger ordering guarantees and
>>> 3) an application programmer may use other, implementation defined,
>>> semantics to provide required ordering guarantees.
>>
>> Isn't (3) true for any MPI call in general, since the user can use
>> implementation-defined alternate mechanisms for any of them?
>>
>> Also, I think we are ignoring the point Jim raised: does OpenSHMEM really
>> need these semantics?
>
> Having pinged Jim, OpenSHMEM doesn't really say anything one way or the other.  They have shmem_*_wait(), but don't actually *say* that you *have* to use it.  Then again, there are a lot of things left unsaid...
>
> (3) might be generally true, but we do have to be careful not to say these things are "undefined".  And, since we are making this hubbub, wouldn't it be nice to include the "why" in the spec?  heck, if we don't, we won't all agree about what we meant by it when next August rolls around...
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma