[Mpi3-rma] MPI-3 UNIFIED model clarification
james.dinan at gmail.com
Wed Jul 31 12:00:36 CDT 2013
I would bet that past Jim suggested striking the polling/eventually
visibile clause and relying on window synchronization to see updates. :)
The downside to this is that libraries like SHMEM that rely on passive
progress and polling, would not be implementable on top of Unified.
Another question that was raised outside of this email discussion is
whether we can rely on the architecture (in the absence of MPI calls) to
make the results of operations visible in the order in which the origin
process expected (e.g. through ordered accumulates, flushes, etc).
On Tue, Jul 30, 2013 at 6:45 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:
> On 07/30/2013 05:33 PM, Sur, Sayantan wrote:
>> On 07/30/2013 10:28 AM, Jim Dinan wrote:
>>>> I believe this is adequately specified on pg 436, line 37. P1 will
>>>> *eventually* see the new value for "a" without any additional
>>>> synchronization operations, but neither the flush by P0 nor the Recv
>>>> P1 guarantee that P1 will see the new value immediately.
>>> This is what I said is the disagreement in the WG. I can pull up the
>>> old email
>>> chain if needed, but I think others can too. One side was arguing that
>>> no such guarantee and you need to do a WIN_SYNC to see the value. The
>>> other side was arguing that the WIN_SYNC should not be needed; FLUSH +
>>> SEND on the origin should be enough.
>> Here's the old thread: http://lists.mpi-forum.org/**
>> Looks like the idea to call MPI_Win_sync for Unified got votes from both
>> Bill and Torsten. Were there others who were in this camp?
> IIRC, Torsten was against it. Jim and I were arguing for it (i.e., having
> to call WIN_SYNC in UNIFIED).
> -- Pavan
> Pavan Balaji
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mpiwg-rma