[mpi-22] Proposal: Correction to one-sided completion semantics, Section 6.7

[Jesper Larsson Traeff]

dear All,

This is a proposal for correction to the semantics of one-sided communication,
Section 6.7 (p. 137ff), where there (in my opinion) is a mistake in
need of correction.

I propose the corrections below for one of the next ballots (probably for
MPI 2.2)

best regards

Jesper

-------------

RATIONALE (not to be put in the standard): the example below - which to my
understanding should be correct - will fail as rules 5 and 6 are now. To
fix, I propose splitting rule 6 into two parts, and making the change from
MPI_WIN_POST to MPI_WIN_WAIT in rule 5

-------------

p. 138, line 21-28 - replace

5. A local update of a location in a private window copy in process memory
   becomes visible in the public window copy at the latest when an ensuing 
   call to MPI_WIN_WAIT, MPI_WIN_FENCE, or MPI_WIN_UNLOCK is executed on 
   that window by the window owner.
6. With active target communication an update by a put or accumulate call to 
   a public window copy becomes visible in the private copy in process memory 
   at the latest when the exposure epoch ends, that is when an ensuing call
   to either MPI_WIN_WAIT or MPI_WIN_FENCE is executed on that window by the
   window owner.
7. With passive target communication an update by a put or accumulate call to 
   a public window copy becomes visible in the private copy in process memory 
   at the latest when the next exposure epoch is started, that is when an 
   ensuing call to either MPI_WIN_POST, MPI_WIN_FENCE or MPI_WIN_LOCK is 
   executed on that window by the window owner.

p. 138, after line 41 - add explanation/examples

The rules (5,6,7) make it possible to switch between synchronization
modes as explained on p. 140, in particular between passive
synchronization and synchronization with post-wait. The following
example illustrates this:

[EXAMPLE]

Process A                        Process B
---------                        ---------

MPI_Win_post(A,B)
MPI_Win_start(A)                 MPI_Win_start(A)
local update of x in A              
                                 MPI_Put(A,y) /* to different location */
MPI_Win_complete                 MPI_Win_complete
MPI_Win_wait

local access to y

----------------------- MPI_Barrier -----------------------

                                 MPI_Win_lock(A)
                                 MPI_Get(A,x)
                                 MPI_Put(A,y) /* to different location */
                                 MPI_Win_unlock(A)

----------------------- MPI_Barrier -----------------------

MPI_Win_Post(A) or MPI_Win_lock(A)
local access to y in A
MPI_Win_wait or MPI_Win_unlock(A)

[END OF EXAMPLE]

Since MPI_WIN_WAIT makes process A's local update to x visible in the
public window (rule 5), it can be accessed by process B after the
first barrier in the access epoch started by MPI_WIN_LOCK. Process B's
update to the public window copy of y can be accessed by process A
after the second barrier (rule 7). The local access to y after
MPI_Win_Wait before the first barrier is guaranteed to access the
value put by process B (rule 6).

Note that in the following (erroneous) passive target communication
example, process A is *not* guaranteed to see the value put by process
B.  In order for A to access the public copy of y it must enter an
exposure epoch by calling either MPI_WIN_LOCK, MPI_WIN_POST, or
MPI_WIN_FENCE.

[EXAMPLE]

Process A                        Process B
---------                        ---------

----------------------- MPI_Barrier -----------------------

                                 MPI_Win_lock(A)
                                 MPI_Put(A,y)
                                 MPI_Win_unlock(A)

----------------------- MPI_Barrier -----------------------

local access to y in A /* unsafe! */

[END OF EXAMPLE]