Subject: RE: Correction to One-sided communications, Section 6.7: Semantics and Correctness To: mpi-21@XXXXXXXXXXXXX X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: Richard Treumann Date: Tue, 1 Apr 2003 16:51:32 -0500 X-MIMETrack: Serialize by Router on D01ML064/01/M/IBM(Release 6.0.1 w/SPR JHEG5JQ5CD|February 20, 2003) at 04/01/2003 16:54:11 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.21 X-Spam-Level: Sender: owner-mpi-21@XXXXXXXXXXXXX Precedence: bulk Reply-To: mpi-21@XXXXXXXXXXXXX Jesper - I agree with Rajeev - the rules are correct as stated. The one I find most obsure (but still correct) is regarding LOCK/UNLOCK. I bet most users would expect the following to be reliable. task 0: MPI_BARRIER(); MPI_WIN_LOCK(1); MPI_PUT(1); MPI_WIN_UNLOCK(1); MPI_BARRIER() task 1: MPI_BARRIER(); MPI_BARRIER(); load from the local window that was MPI_PUT from task 0. The need for MPI_WIN_LOCK(1); or some other synch at task 1 before accessing the window by load would be a surprise to many users. They would recognize the need to lock before PUT(1), GET(1) or ACCUMULATE(1) but not load/store. Dick Dick Treumann RS/6000 SP Development IBM Poughkeepsie Unix Development Lab Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 "Rajeev Thakur" ov> cc: Sent by: Subject: RE: Correction to One-sided communications, Section 6.7: Semantics and owner-mpi-21@mpi- Correctness forum.org 04/01/2003 12:12 PM Please respond to mpi-21 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 > >