<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Sep 23, 2018 at 3:25 AM Rolf Rabenseifner via mpiwg-rma <<a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Bill,<br>
<br>
1. MPI-3.1 after MPI_Win_UNLOCK_ALL, page 448 lines 1-4 read<br>
<br>
    Implementors may restrict the use of RMA communication that <br>
    is synchronized by lock calls to windows in memory allocated <br>
    by MPI_ALLOC_MEM (Section 8.2), MPI_WIN_ALLOCATE (Section 11.2.2), <br>
    or attached with MPI_WIN_ATTACH (Section 11.2.4). <br>
    Locks can be used portably only in such memory.<br>
<br>
   but should read<br>
<br>
    Implementors may restrict the use of RMA communication that <br>
    is synchronized by lock calls to windows in memory allocated <br>
    by MPI_ALLOC_MEM (Section 8.2), MPI_WIN_ALLOCATE (Section 11.2.2), <br>
      MPI_WIN_ALLOCATE_SHARED (Section 11.2.3),<br>
    or attached with MPI_WIN_ATTACH (Section 11.2.4). <br>
    Locks can be used portably only in such memory.<br>
<br>
<br></blockquote><div><br></div><div>I am not certain that this change is consistent with the original intent, but we should just remove this text, because it does not make sense anymore.  If MPI_Win_attach is sufficient to allow locks, then MPI_Win_create should be there, because one can implement MPI_Win_create in terms of MPI_Win_create_dynamic+MPI_Win_attach.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. In MPI-3.1 Section 11.5.5 Assertions, the wording of data <br>
   transfer assertions does not fit to shared memory windows.<br>
   I expect the fact is clear because the window portions <br>
   of process rank a can be written  or read by all process<br>
   using direct language assignments or expressions, respectively,<br>
   instead of only using RMA calls and direct accesses only to<br>
   the own window Portion.<br>
<br>
   Therefore, I would add at the end of the following items<br>
    - MPI_WIN_POST: MPI_MODE_NOSTORE and MPI_MODE_NOPUT<br>
    - MPI_WIN_FENCE: at all four assertions<br>
   the following sentence:<br>
<br>
     This assertion does not apply and is therefore ignored<br>
     in the case of a window created with MPI_WIN_ALLOCATE_SHARED.<br>
<br></blockquote><div><br></div><div>I thought I created a ticket to make the window assertions more consistent.  I don't know if it was migrated to GitHub or not.</div><div><br></div><div>Jeff</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Best regards<br>
Rolf<br>
<br>
<br>
----- Original Message -----<br>
> From: "MPI WG Remote Memory Access working group" <<a href="mailto:mpiwg-rma@lists.mpi-forum.org" target="_blank">mpiwg-rma@lists.mpi-forum.org</a>><br>
> To: "MPI WG Remote Memory Access working group" <<a href="mailto:mpiwg-rma@lists.mpi-forum.org" target="_blank">mpiwg-rma@lists.mpi-forum.org</a>><br>
> Cc: "wgropp" <<a href="mailto:wgropp@illinois.edu" target="_blank">wgropp@illinois.edu</a>><br>
> Sent: Friday, September 21, 2018 3:52:07 PM<br>
> Subject: [mpiwg-rma] Summary of MPI RMA WG meeting on Sept 21, 2018<br>
<br>
> MPI RMA Working Group Meeting<br>
> September 21, 2018<br>
> Barcelona, Spain<br>
> <br>
> (I couldn’t find the RMA wiki - did this never get migrated?)<br>
> <br>
> Here are my notes. For those present, please let me know if I missed anything.<br>
> <br>
> - Interoperability of MPI shared memory with C11, C++11 language semantics.<br>
> Lead: Bill Gropp<br>
> <br>
> No document.<br>
> <br>
> Discussion. WG agreed that MPI should remain as consistent as possible with the<br>
> language standards as they go forward, noting that there are still limitations<br>
> in their descriptions of shared memory.<br>
> <br>
> - MPI Generalized atomics. Lead: Pavan Balaji<br>
> <br>
> PDF attached.<br>
> <br>
> Generally positive response to the text. A few suggestions were made:<br>
> For accumulate_op - allow compare-and-swap (CAS) with another op (as an option)<br>
> For which_accumulate_op - Consider a comma-separated list of operators<br>
> for accumulate_max_bytes. There was a discussion about whether this should be<br>
> count or bytes, and how exactly to describe what the max means in terms of<br>
> parameters to the accumulate operations.<br>
> <br>
> - Neighborhood communication in RMA. Lead: Nathan Hjelm<br>
> <br>
> No document.<br>
> <br>
> Nathan presented the basic ideas, which is the use of the topology attached to a<br>
> communicator to limit the permitted communication partners, and thus simplify<br>
> and reduce the memory requirements in the implementation.<br>
> <br>
> The WG was interested, and on a straw vote of 6-0-2, asked for a more detailed<br>
> presentation (e.g., a Powerpoint, not yet a written standard proposal),<br>
> <br>
> - Nonblocking RMA synchronization. Lead: Pavan Balaji<br>
> <br>
> No document, but this might be absorbed by TonyS's proposal.<br>
> <br>
> The WG would like a top-level conceptual discussion of this in the context of<br>
> MPI.<br>
> <br>
> - RMA Notify. Leads: Jim and Torsten<br>
> <br>
> [ <a href="https://github.com/mpi-forum/mpi-issues/issues/59" rel="noreferrer" target="_blank">https://github.com/mpi-forum/mpi-issues/issues/59</a> |<br>
> <a href="https://github.com/mpi-forum/mpi-issues/issues/59" rel="noreferrer" target="_blank">https://github.com/mpi-forum/mpi-issues/issues/59</a> ]<br>
> <br>
> Some discussion. Noted that the state-of-the-art has advanced since the last<br>
> discussion in detail by the working group. The WG, on a 7-0-1 straw vote, would<br>
> like an update to the possible options here. It was also noted that Bull is<br>
> experimenting with different options in different systems, and may be able to<br>
> share the results in a few months.<br>
> <br>
> One question to consider is the pros and cons of using requests as the<br>
> notification mechanism; it was noted that one pragmatic if not elegant solution<br>
> might be to allow both a heavy (e.g., MPI_Request) and lightweight (e.g.,<br>
> memory variable) notification approach.<br>
> <br>
> - MPI_IN_PLACE semantics for collectives on shared memory. Lead: Pavan Balaji<br>
> <br>
> PDF attached.<br>
> <br>
> This was reviewed by the WG. When asked whether there was interest in a document<br>
> with a usage example and discussion of benefits, the WG voted no in a straw<br>
> poll with 0-4-2 (and 2 not voting).<br>
> <br>
> - Relax constraints on MPI_WIN_SHARED_QUERY. Lead: Jeff Hammond<br>
> <br>
> [ <a href="https://github.com/mpi-forum/mpi-issues/issues/23" rel="noreferrer" target="_blank">https://github.com/mpi-forum/mpi-issues/issues/23</a> |<br>
> <a href="https://github.com/mpi-forum/mpi-issues/issues/23" rel="noreferrer" target="_blank">https://github.com/mpi-forum/mpi-issues/issues/23</a> ]<br>
> <br>
> The WG found support for this and voted 5-1-2 for a full written proposal<br>
> <br>
> - Add flush_thread synchronization calls. Lead: Nathan Hjelm<br>
> <br>
> No document.<br>
> <br>
> Nathan presented this and the WG voted 7-0-2 for a more detailed (e.g., a<br>
> Powerpoint) description.<br>
> <br>
> The WG would like to see the written proposals for generalized atomics and<br>
> shared_query in time for reading at the December MPI Forum meeting.<br>
> <br>
> <br>
> The WG adjourned after discussing these items.<br>
> <br>
> William Gropp<br>
> Director and Chief Scientist, NCSA<br>
> Thomas M. Siebel Chair in Computer Science<br>
> University of Illinois Urbana-Champaign<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> mpiwg-rma mailing list<br>
> <a href="mailto:mpiwg-rma@lists.mpi-forum.org" target="_blank">mpiwg-rma@lists.mpi-forum.org</a><br>
> <a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma</a><br>
<br>
-- <br>
Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de" target="_blank">rabenseifner@hlrs.de</a> .<br>
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 .<br>
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 .<br>
Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner" rel="noreferrer" 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" target="_blank">mpiwg-rma@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div></div>