Draft Agenda for MPI RMA Working Group: September 2016

RMA Working Group

Open Issues

Working group issues

• #1 Attributes on MPI windows
  Type of the attributes (integer, but what kind of integer)
  Next steps: Bill to propose text
• #2 Deprecate usage of MPI_MINLOC and MPI_MAXLOC with accumulate
  Long discussion that veered into the rationale behind the restrictions on MPI_Accumulate an friends to only allow predefined operators (including these two).
  Next steps: Still pending. Could benefit with a summary of the discussion, separating out the different issues.

MPI Forum issues

• #23 relax constraints on MPI_WIN_SHARED_QUERY
  Allow this routine to be called for any (non-Dynamic) Window in case the implementation has used shared memory.
  Next steps: make reading for a reading; need precise text and all issues addressed.
• #24 new assertions for passive-target epochs
  A collection of additional assertions to be used in the passive target case. Consider each independently.
  Next steps: Take first 4 asserts and make them into a proposal with complete text. Remaining two need more discussion.
• #31 MPI_COMM_TYPE_ADDRESS_SPACE
  New comm_split_type type for MPI processes that share an address space (not strictly RMA, but impacts RMA chapter)
  Next steps: Ignore while the hybrid group considers.
• #36 MPI Accumulate operation restrictions
  Provide a way to allow any combination of operations to the same location in RMA accumulate operations (possibly as the default)
  Next steps: Pavan to provide text.
• #37 Errata: MPI Active Target synchronization requirements
  The infamous 434; the todo is to draft some clarifying text. Need to assign this task.
  Next steps: Bill to draft text.
• #38 Errata: MPI Unified window clarification
  Clarify synchronization text.
  Next steps: Text shold describe the problem in more detail (the specific shared memory issues). Pavan to lead text change with help from Bill and Rajeev and rest of RMA WG.
• #39 Interpretation of MPI_WIN_BASE for shared memory windows
  What does MPI_WIN_BASE mean for MPI_Win_allocate_shared? A preference was selected at a previous meeting, but next steps are needed.
  Need complete and specific text for option 1. Ask Jeff to create.
• #40 deprecate MPI_WIN_SYNC
  Rely on the language rather than Win_sync
  Next step: Close as will-not-do.
• #41 extend MPI_WIN_SYNC for Fortran
  An alternative to the above, intended for Fortran.
  Next step: Close as will-not-do
• #42 advice to users about MPI shared memory and C(++)11
  As above, but targeted at C/C++ 11 users
  Next step: Need specific text for the advice to users. Bill to do?
• #46 fine-grain specification of RMA op+type in window info(x
  Place holder for a proposals from the old wiki, but not yet in a form to discuss
  Pavan and Jeff to handle; disposition is to close this one or greatly restrict it.
• #47 RMA sync ops with vector of windows
  Provide a way to use a single call to synchronize a vector of MPI_Win objects
  Next steps: Link with discussion of non-blocking epochs and decide in that context.
• #48 RMA Notification
  Add notification to passive-target
  Next steps: Add note that closed because (a) can use send/receive and (b) too tightly connected to specific hardware capabilities.
• #49 Allow MPI_Win_sync outside of RMA epoch
  As it says, though the proposed text is broader and probably needs to be tightened.
  Next steps: Ask for use case; note that one approach is to call lockall immediately after creating the window and never unlocking until right before the win_free.
• #59 RMA Notification
  Mostly a duplicate to the RMA Notification above, but with more comments
  Next steps: as #48 above.
• #61 Errata for Passive Target RMA on shared memory
  Clear errata on text with simple fix
  Next steps: straw vote to consider as level 0 errata, though still needs to be added to errata page.