[mpich-discuss] MPI RMA

[Jim Dinan]

+1

It's a bit confusing, but both of those examples that Nick included are 
correct usages of fence.

  ~Jim.

On 2/8/13 11:58 AM, Jeff Hammond wrote:
>  From MPI-3 11.5.1:
>
> - The MPI call MPI_WIN_FENCE(assert, win) synchronizes RMA calls on win.
> - The call completes an RMA access epoch if it was preceded by another
> fence call and the local process issued RMA communication calls on win
> between these two calls.
> - The call completes an RMA exposure epoch if it was preceded by
> another fence call and the local window was the target of RMA accesses
> between these two calls.
> - The call starts an RMA access epoch if it is followed by another
> fence call and by RMA communication calls issued between these two
> fence calls.
> - The call starts an exposure epoch if it is followed by another fence
> call and the local window is the target of RMA accesses between these
> two fence calls.
>
> MPI_Win_fence may both start or complete an RMA epoch but it may also
> complete-one-and-start-another RMA epoch depending on the context and
> the assertions.  All of the tests below are valid in my opinion.
>
> What the assertions below in the first example are saying is that the
> first call to MPI_Win_fence need not complete any RMA calls, which is
> true because it is the first sync call.  The last MPI_Win_fence
> asserts the same thing in reverse.  The middle one asserts nothing
> because it is both completing and starting an epoch.
>
> I think that MPI_Win_fence is poorly designed but that ship has sailed
> and I believe that the usage is well-defined in the standard despite
> the confusing properties of this function.
>
> Jeff
>
> On Fri, Feb 8, 2013 at 11:36 AM, Nick Radcliffe <nradclif at cray.com> wrote:
>> Hi,
>>
>> I have a question about MPI RMA, and the ANL regression tests for RMA in particular. The tests mixedsync.c and epochtest.c seem to have contradictory views of fence synchronization.
>>
>> epochtest.c seems to suggest that access/exposure epochs opened by a call to MPI_Win_fence are not closed until a call to MPI_Win_fence with assert==MPI_MODE_NOSUCCEED. The test looks roughly like this:
>>
>> MPI_Win_fence(MPI_MODE_NOPRECEDE, win)
>> if (rank == src) MPI_Put
>> MPI_Win_fence(0, win)
>> if (rank == dest) MPI_Put
>> etc...
>> MPI_Win_fence(MPI_MODE_NOSUCCEED, win)
>>
>> Since there is a call to MPI_Put after the second call to MPI_Win_fence, it would seem that the second call could not have ended the access epoch for dest, or the exposure epoch for src (which is the target of the second Put).
>>
>> On the other hand, the test mixedsync.c looks roughly like this:
>>
>> if (rank == src) {
>>      MPI_Win_lock(...,win)
>>      MPI_Put
>>      MPI_Win_unlock(...,win)
>> }
>>
>> MPI_Win_fence(0, win)
>> if (rank == src) MPI_Put
>> MPI_Win_fence(0, win)
>>
>> if (rank == src) {
>>      MPI_Win_lock(...,win)
>>      MPI_Put
>>      MPI_Win_unlock(...,win)
>> }
>>
>> The problem is that it is erroneous to call MPI_Win_lock on a window while that window is exposed due to a call to MPI_Win_fence. If mixedsync.c is not erroneous, then the second call to MPI_Win_fence must end the exposure epoch on win, contradicting what's implied about fence synchronization by epochtest.c.
>>
>> Sorry for the long post, but if anyone can shed some light on this for me, I would greatly appreciate it.
>>
>> _______________________________________________
>> discuss mailing list     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
>
>
>