From: "Rajeev Thakur" <thakur@XXXXXXXXXXX>
To: <mpi-21@XXXXXXXXXXXXX>
Subject: RE: Correction to One-sided communications, Section 6.7: Semantics and Correctness
Date: Tue, 1 Apr 2003 11:12:16 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <20030401125309.GA21013@XXXXXXXXXXXXXXXXXXXX>
X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.21
X-Spam-Level: 
Sender: owner-mpi-21@XXXXXXXXXXXXX
Precedence: bulk
Reply-To: mpi-21@XXXXXXXXXXXXX

Jesper,
       I think the wording is correct the way it is. Rule 5 specifies when a
local update made by a process to its own window becomes visible to others.
In the case of post-wait synchronization, it becomes visible at the latest
when MPI_Win_post is called by that process. MPI_Win_post "exposes" the
local window to other processes, so it is right to say that the local update
must have occured before post is called, and post makes it visible to other
processes.

Similarly, Rule 6 specifies when the update made by a remote process becomes
visible to the local process. In the case of post-wait synchronization,
clearly, it is MPI_Win_wait that "completes" the operation, and therefore
only after win_wait is called can one expect the update made by the remote
process to be visible to the local process.

Rajeev



> -----Original Message-----
> From: owner-mpi-21@mpi-forum.org [mailto:owner-mpi-21@mpi-forum.org]On
> Behalf Of Jesper Larsson Traeff
> Sent: Tuesday, April 01, 2003 6:53 AM
> To: mpi-21@mpi-forum.org
> Subject: Correction to One-sided communications, Section 6.7: Semantics
> and Correctness
>
>
>
> Dear MPI-2 Group,
>
> the list has been silent for quite some time. Here's an error (I
> think) and
> an issue concerning semantics of one-sided communications, that might
> reactivate discussions.
>
> MPI-2, Section 6.7: Semantics and Correctness of one-sided communications
>
> The rules on p.138 explain when operations are to complete at origins and
> targets, and in particular when updates become visible in public
> and private
> copies of windows.
>
> To my understanding:
> Rule 5 should state that an update in a location in a private window copy
> of a process becomes visible in the public window when that
> process perform
> a synchronization operation to end the current exposure epoch, that is an
> MPI_WIN_FENCE, MPI_WIN_UNLOCK or MPI_WIN_WAIT (and *not*, as written,
> MPI_WIN_POST)
>
> Rule 6 should state that an update to a public window becomes visible in
> the private window of the process owning the locations when the
> window owner
> opens the next exposure epoch, that is after the next MPI_WIN_FENCE,
> MPI_WIN_LOCK or MPI_WIN_POST (and *not*, as written, MPI_WIN_WAIT)
>
> Thus, it seems that in rules 5 and 6 the roles of MPI_WIN_POST
> and MPI_WIN_WAIT
> where falsely swapped. Is that so?
>
> The issue here is quite subtle and maybe some "advice to users"
> should be added.
> The MPI-2 standard apparently only guarantees eg. cache coherence
> (on a window)
> after the opening the next access epoch (Rule 6). Barrier
> synchronization or
> explicit synchronization with send/recv's alone does not
> guarantee this! This
> can likely confuse users who end, say, a phase in a application
> using MPI-lock
> synchronization with an explicit MPI_Barrier, and after the barrier expect
> all data now to be visible in the private window copies. In some MPI
> implementations or for some architectures that may not be so!
>
> Regards
>
> Jesper
>
>