From: "Rajeev Thakur" To: Subject: RE: Correction to One-sided communications, Section 6.7: Semantics and Correctness Date: Fri, 4 Apr 2003 11:11:49 -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) In-Reply-To: <20030404114949.GB27057@XXXXXXXXXXXXXXXXXXXX> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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 > As far as I remember, the standard does try to enforce that local > load/store > accesses within epochs behave sensibly; for instance on p.132 it says that > an MPI_Win_lock used to lock the local window must block, "since > the lock may > protect local load/store accesses". > > I propose to make the correction to the standard I suggested, that > is, swap POST and WAIT in rules 5 and 6 (as it is now, is just a > mistake, I think) Jesper, Swapping Post and Wait in rules 5 and 6 won't be sufficient. We would have to allow both Post and Wait in both rules 5 and 6. For example, if Rule 5 says Wait instead of Post, then the following example won't work: Process A Process B local update Win_Post Win_start MPI_Get Win_Wait Win_complete If Win_post doesn't make the local update visible, MPI_Get may not see it. Similarly for Rule 6, if it says Post instead of Wait, the following example won't work Process A Process B Win_Post Win_start MPI_Put Win_Wait Win_complete local access If Win_wait doesn't make the result of MPI_Put locally visible, the local access won't see it. Rajeev