<div dir="ltr"><div>Hmm.  That is also a good place for this.  I could go either way.  Do others have a preference on where this advice appears (<span style="font-family:arial,sans-serif;font-size:13px">p457:3 or p451:3).</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 20, 2014 at 11:40 AM, Rolf Rabenseifner <span dir="ltr"><<a href="mailto:rabenseifner@hlrs.de" target="_blank">rabenseifner@hlrs.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I added your "and threads" in<br>
<a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/413" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/413</a><br>
but I would put it in the same Section 11.7 as the example,<br>
<br>
i.e. on p457:3 instead of p451:3.<br>
<br>
okay?<br>
<div class="im HOEnZb"><br>
Best regards<br>
Rolf<br>
<br>
<br>
<br>
----- Original Message -----<br>
> From: "Jim Dinan" <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>><br>
> To: "MPI WG Remote Memory Access working group" <<a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a>><br>
</div><div class="HOEnZb"><div class="h5">> Sent: Thursday, February 20, 2014 5:25:06 PM<br>
> Subject: Re: [mpiwg-rma] [Mpi-forum] 3/14: Formal Readings<br>
><br>
><br>
><br>
> Thinking about this more, we should also mention threads.  Here's an<br>
> updated draft.  I propose that we incorporate this change with<br>
> Rolf's example (the X.YY should reference Rolf's example).  The<br>
> following text would be added to page 451, line 3:<br>
><br>
><br>
> Advice to users: MPI_WIN_SYNC can be used to order store operations<br>
> and make store updates to the window visible to other processes and<br>
> threads.  Use of this routine is necessary to ensure portable<br>
> behavior when point-to-point, collective, or shared memory<br>
> synchronization is used in place of an RMA synchronization routine.<br>
>  MPI_WIN_SYNC should be called by the writer before the non-RMA<br>
> synchronization operation and called by the reader after the non-RMA<br>
> synchronization, as shown in Example X.YY.<br>
><br>
><br>
><br>
>  ~Jim.<br>
><br>
><br>
><br>
> On Thu, Feb 20, 2014 at 6:43 AM, Jim Dinan < <a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
> Hi Rolf,<br>
><br>
><br>
> I agree -- we have had several discussions in the RMA WG about this<br>
> ambiguity, but I don't think we have a proposal for a clarification.<br>
>  I think the consensus was that MPI 3.0 is technically correct,<br>
> albeit it hard to understand.  Can we add an MPI_WIN_SYNC advice to<br>
> users to your proposal?<br>
><br>
><br>
> Advice to users: MPI_WIN_SYNC can be used to order store operations<br>
> and make store updates to the window visible to other processes.<br>
>  Use of this routine is necessary to ensure portable behavior when<br>
> point-to-point, collective, or shared memory synchronization is used<br>
> in place of an RMA synchronization routine.  MPI_WIN_SYNC should be<br>
> called by the writer before the non-RMA synchronization operation<br>
> and by the reader after the non-RMA synchronization, as shown in<br>
> Example X.YY.<br>
><br>
><br>
>  ~Jim.<br>
><br>
><br>
><br>
><br>
><br>
> On Thu, Feb 20, 2014 at 4:55 AM, Rolf Rabenseifner <<br>
> <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
><br>
><br>
> Jeff,<br>
><br>
> the problem is that we are in the unified model.<br>
><br>
> I expect that nobody would expect that<br>
><br>
><br>
>   "the purposes of synchronizing the private and public window"<br>
><br>
> (from your cited text) is needed if<br>
><br>
>   "public and private copies are identical",<br>
><br>
> see MPI-3.0 p436:37-40, which say<br>
><br>
> "In the RMA unified model, public and private copies are identical<br>
> and updates via put<br>
> or accumulate calls are eventually observed by load operations<br>
> without additional RMA<br>
> calls. A store access to a window is eventually visible to remote get<br>
> or accumulate calls<br>
> without additional RMA calls."<br>
><br>
> MPI-3.0 p456:3ff say<br>
><br>
> "In the MPI_WIN_UNIFIED memory model, the rules are much simpler<br>
> because the public<br>
> and private windows are the same. ..."<br>
><br>
> and especially p456:34-36<br>
><br>
> "This permits updates to memory with<br>
> store operations without requiring an RMA epoch."<br>
><br>
> I read all this text and thought that I do not need any additional<br>
> synchronization besides the (empty) pt-to-pt Messages.<br>
> The members of the RMA working group convinced me<br>
> that the MPI_WIN_SYNC is needed to guarantee that a locally<br>
> visible X=13 may not be remote visible without the MPI_WIN_SYNC<br>
> although the MPI-3.0 text clearly says<br>
> "in the RMA unified model, public and private copies are identical".<br>
><br>
> Currently, there is no example in this section showing the behavior<br>
> in the unified model with only using load/store, i.e. without any<br>
> RMA call. All existing examples use some PUT or GET.<br>
><br>
> I tried to fill this gap to prevent any mis-interpretation<br>
> of p436:37-40 and p456:3-p457:3.<br>
><br>
><br>
> Best regards<br>
> Rolf<br>
><br>
><br>
> ----- Original Message -----<br>
><br>
> > From: "Jeff Hammond" < <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a> ><br>
> > To: "MPI WG Remote Memory Access working group" <<br>
> > <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a> ><br>
><br>
><br>
> > Cc: "Jeff Squyres" < <a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a> ><br>
> > Sent: Wednesday, February 19, 2014 7:19:14 PM<br>
> > Subject: Re: [mpiwg-rma] [Mpi-forum] 3/14: Formal Readings<br>
> ><br>
> > Other than interactions that are unique to Fortran, I do not<br>
> > understand what is unclear about the following text from MPI-3:<br>
> ><br>
> > "For the purposes of synchronizing the private and public window,<br>
> > MPI_WIN_SYNC has the effect of ending and reopening an access and<br>
> > exposure epoch on the window."<br>
> ><br>
> > Thus, the valid usage is prescribed by its effective equivalence to<br>
> > "MPI_WIN_UNLOCK; MPI_WIN_LOCK;".  I apologize if the WG has been<br>
> > sloppy in how we've discussed MPI_WIN_SYNC, but I do not feel the<br>
> > standard is ambiguous.<br>
> ><br>
> > Now, if you are arguing that Fortran is a special problem for<br>
> > MPI_WIN_SYNC, then I will gladly support your argument that Fortran<br>
> > is<br>
> > a special problem for lots of things :-)<br>
> ><br>
> > Jeff<br>
> ><br>
> > On Wed, Feb 19, 2014 at 11:44 AM, Rolf Rabenseifner<br>
> > < <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
> > > Jim,<br>
> > ><br>
> > > Yes Jim, you are fully right and I updated ticket 413 according<br>
> > > to<br>
> > > your corrections.<br>
> > > Thank you for your carefully reading and your corrections.<br>
> > ><br>
> > > The reason for this ticket is very simple:<br>
> > > Nothing about the use of MPI_Win_sync for the use-case<br>
> > > in this example is really explained by MPI-3.0.<br>
> > > I expect, that for MPI-4.0, the rules for RMA synchronization<br>
> > > for shared memory windows must be revisited.<br>
> > > But this would be another ticket.<br>
> > ><br>
> > > Best regards<br>
> > > Rolf<br>
> > ><br>
> > > ----- Original Message -----<br>
> > >> From: "Jim Dinan" < <a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a> ><br>
> > >> To: "MPI WG Remote Memory Access working group"<br>
> > >> < <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a> ><br>
> > >> Cc: "Rolf Rabenseifner" < <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> >, "Jeff Squyres"<br>
> > >> < <a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a> ><br>
> > >> Sent: Monday, February 17, 2014 11:30:42 PM<br>
> > >> Subject: Re: [mpiwg-rma] [Mpi-forum] 3/14: Formal Readings<br>
> > >><br>
> > >><br>
> > >> Rolf,<br>
> > >><br>
> > >><br>
> > >> I think this ticket needs to be reviewed by the RMA WG before<br>
> > >> moving<br>
> > >> it forward.  I would suggest updating the text to incorporate<br>
> > >> the<br>
> > >> following changes:<br>
> > >><br>
> > >><br>
> > >> Example 11.13 demonstrates the proper synchronization in the<br>
> > >> unified<br>
> > >> memory model when a data transfer is implemented with load and<br>
> > >> store<br>
> > >> (instead of MPI_PUT or MPI_GET) and the synchronization between<br>
> > >> processes is performed using point-to-point communication. The<br>
> > >> synchronization between processes must be supplemented with a<br>
> > >> memory<br>
> > >> synchronization through calls to MPI_WIN_SYNC, which act locally<br>
> > >> as<br>
> > >> a processor-memory barrier.  In Fortran, reordering of the<br>
> > >> MPI_WIN_SYNC calls must be prevented with MPI_F_SYNC_REG<br>
> > >> operations.<br>
> > >><br>
> > >> The variable X is contained within a shared memory window and X<br>
> > >> corresponds to the same memory location at both processes. The<br>
> > >> MPI_WIN_SYNC operation performed by process A ensures completion<br>
> > >> of<br>
> > >> the load/store operations issued by process A. The MPI_WIN_SYNC<br>
> > >> operation performed by process B ensures that process A's<br>
> > >> updates<br>
> > >> to<br>
> > >> X are visible to process B.<br>
> > >><br>
> > >> In the example, I don't see the reason for the second set of<br>
> > >> SYNC<br>
> > >> operations after B's read of X.  If A updates X and B only reads<br>
> > >> it,<br>
> > >> the second send/recv synchronization should be sufficient.  That<br>
> > >> is,<br>
> > >> B has not made any updates to X that need to be made visible A,<br>
> > >> and<br>
> > >> B's read of X will be ordered because of the send operation.<br>
> > >>  The<br>
> > >> F_SYNC could still be needed to preserve this ordering.<br>
> > >><br>
> > >><br>
> > >>  ~Jim.<br>
> > >><br>
> > >><br>
> > >><br>
> > >> On Mon, Feb 17, 2014 at 12:23 PM, Jeff Hammond <<br>
> > >> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a> > wrote:<br>
> > >><br>
> > >><br>
> > >> Switching to the WG list so that everyone is involved...<br>
> > >><br>
> > >> I do not see adding an example as so urgent that it needs to be<br>
> > >> dealt<br>
> > >> with at the next meeting, given how overloaded the relevant<br>
> > >> people<br>
> > >> are.<br>
> > >><br>
> > >> Honestly, it is more likely to be read by users if the example<br>
> > >> and<br>
> > >> commentary on it are the subject of a blog post on Squyres'<br>
> > >> blog.<br>
> > >>  At<br>
> > >> the very least, that will ensure Google indexes it and thus<br>
> > >> curious<br>
> > >> people will find it (as much cannot be said for the MPI standard<br>
> > >> itself).<br>
> > >><br>
> > >> Jeff<br>
> > >><br>
> > >><br>
> > >><br>
> > >> On Mon, Feb 17, 2014 at 10:50 AM, Rolf Rabenseifner<br>
> > >> < <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
> > >> > Pavan,<br>
> > >> ><br>
> > >> > do you put also #413 on the list.<br>
> > >> > I believe, it's better to have it on the list<br>
> > >> > although it is only an example and therefore the RMA group<br>
> > >> > may put it on the errata without plenary.<br>
> > >> > Please can you do all what is needed<br>
> > >> > that it comes on the MPI-3.0 errata list.<br>
> > >> ><br>
> > >> > Best regards<br>
> > >> > Rolf<br>
> > >> ><br>
> > >> >> Pavan,<br>
> > >> >>    thank you for supporting it in the March meeting (Rajeev<br>
> > >> >>    will<br>
> > >> >> not<br>
> > >> >>    be there).<br>
> > >> >>    Is there a RMA WG Meeting at the March Forum Meeting?<br>
> > >> >>    Will you do an MPI-3.0 errata plenary reading<br>
> > >> >>    or will you put it into the errata by WG dicision,<br>
> > >> >>    because it is only an example?<br>
> > >> >>    In both cases #413 should be latest tomorrow on the<br>
> > >> >> agenda.<br>
> > >> >><br>
> > >> >>    Because it is one block of text at one precise location,<br>
> > >> >>    the ticket format may be enough formalism, i.e., no extra<br>
> > >> >>    pdf.<br>
> > >> ><br>
> > >> > ----- Original Message -----<br>
> > >> >> From: "Jim Dinan" < <a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a> ><br>
> > >> >> To: "Main MPI Forum mailing list" <<br>
> > >> >> <a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>
> > >> >> ><br>
> > >> >> Sent: Monday, February 17, 2014 4:35:51 PM<br>
> > >> >> Subject: [Mpi-forum] 3/14: Formal Readings<br>
> > >> >><br>
> > >> >><br>
> > >> >><br>
> > >> >> Hi All,<br>
> > >> >><br>
> > >> >><br>
> > >> >> The RMA and Hybrid working groups would like to put forward<br>
> > >> >> the<br>
> > >> >> following tickets for formal readings at the upcoming<br>
> > >> >> meeting:<br>
> > >> >><br>
> > >> >><br>
> > >> >> #380 - Endpoints proposal<br>
> > >> >><br>
> > >> >><br>
> > >> >> <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/380/mpi-report.pdf" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/380/mpi-report.pdf</a><br>

> > >> >><br>
> > >> >><br>
> > >> >> Read by: Pavan Balaji<br>
> > >> >><br>
> > >> >><br>
> > >> >> #349, #402, #404 - Address arithmetic proposal<br>
> > >> >><br>
> > >> >><br>
> > >> >><br>
> > >> >> <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/349/review-349-402-404.pdf" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/349/review-349-402-404.pdf</a><br>

> > >> >><br>
> > >> >><br>
> > >> >><br>
> > >> >> Read by: David Goodell<br>
> > >> >> #369 - Add same_disp_unit info key for RMA window creation<br>
> > >> >><br>
> > >> >><br>
> > >> >><br>
> > >> >> <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/369/mpi-report.2.pdf" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/369/mpi-report.2.pdf</a><br>

> > >> >><br>
> > >> >><br>
> > >> >><br>
> > >> >> Read by: Pavan Balaji<br>
> > >> >><br>
> > >> >> Please add these to the agenda.  Unfortunately, I will not be<br>
> > >> >> able<br>
> > >> >> to<br>
> > >> >> attend this meeting, so I have included a contact person for<br>
> > >> >> each<br>
> > >> >> ticket.<br>
> > >> >><br>
> > >> >><br>
> > >> >> Thanks!<br>
> > >> >>  ~Jim.<br>
> > >> >> _______________________________________________<br>
> > >> >> mpi-forum mailing list<br>
> > >> >> <a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>
> > >> >> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
> > >> ><br>
> > >> > --<br>
> > >> > Dr. Rolf Rabenseifner . . . . . . . . . .. email<br>
> > >> > <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
> > >> > High Performance Computing Center (HLRS) . phone<br>
> > >> > <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
> > >> > University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<br>
> > >> > 685-65832<br>
> > >> > Head of Dpmt Parallel Computing . . .<br>
> > >> > <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
> > >> > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room<br>
> > >> > 1.307)<br>
> > >><br>
> > >><br>
> > >><br>
> > >> --<br>
> > >> Jeff Hammond<br>
> > >> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
> > >> _______________________________________________<br>
> > >> mpiwg-rma mailing list<br>
> > >> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
> > >> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
> > >><br>
> > >><br>
> > ><br>
> > > --<br>
> > > Dr. Rolf Rabenseifner . . . . . . . . . .. email<br>
> > > <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
> > > High Performance Computing Center (HLRS) . phone<br>
> > > <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
> > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<br>
> > > 685-65832<br>
> > > Head of Dpmt Parallel Computing . . .<br>
> > > <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
> > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room<br>
> > > 1.307)<br>
> > > _______________________________________________<br>
> > > mpiwg-rma mailing list<br>
> > > <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
> > > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Jeff Hammond<br>
> > <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
> > _______________________________________________<br>
> > mpiwg-rma mailing list<br>
> > <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
> > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
> ><br>
><br>
> --<br>
> Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
> High Performance Computing Center (HLRS) . phone <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
> University of Stuttgart . . . . . . . . .. fax <a href="tel:%2B%2B49%280%29711%20%2F%20685-65832" value="+4971168565832">++49(0)711 / 685-65832</a><br>
> Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)<br>
> _______________________________________________<br>
> mpiwg-rma mailing list<br>
> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> mpiwg-rma mailing list<br>
> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
<br>
--<br>
Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
High Performance Computing Center (HLRS) . phone <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
University of Stuttgart . . . . . . . . .. fax <a href="tel:%2B%2B49%280%29711%20%2F%20685-65832" value="+4971168565832">++49(0)711 / 685-65832</a><br>
Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)<br>
_______________________________________________<br>
mpiwg-rma mailing list<br>
<a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a></div></div></blockquote></div><br></div>