RMA WG 08 16 2018

Agenda

1. Atomicity Clarifications Feedback
2. Put with Signal Feedback
3. Memory Model Proposal (Anshuman Goswami)
4. Wait-some and test-some

Attendees

• Intel (Dave)
• ORNL (Manju)
• NVIDIA (Anshuman)
• DOD (Nick)
• Cray (Naveen)

Open Action Items

• None

Action Items

• None

Notes

Atomicity Clarifications

• Originally, touched memory model, put-with-signal, and wait/test atomicity with definition of "atomic compatible".
• Recent update(s) removed notion of "atomic compatible".
• Dave unsure of status for OpenSHMEM F2F next week.

Put-with-Signal

• Naveen will bring blocking put-with-signal (#218) for Special Ballot next week and nonblocking put-with-signal (#238) for reading.
• While it will be moving forward, the put-with-signal proposal(s) are affected by the wait/test atomicity interactions with the memory model.

Memory Model

• Currently, the memory model topic split over multiple issues (#229 is the "umbrella" issue).
• Anshuman would like clarification from community on ordering of blocking gets (#233). Should a fence be required to order two blocking get operations or not?
• Anshuman noted that the pSync semantics in collectives differ; e.g., between broadcast and collect. Is this intentional?

Test/Wait Some

• Dave asked for input whether this PR should have a formal or informal reading at the F2F.
• Recent changes include:
  • Reintroduced indices array
  • Allows for status array to be optional
  • Sets type of status array to be int*
  • Requires the ivars and indices arrays to be at least nelems long
• Discussed the "some"-ness of test_some
  • Should shmem_test_some be required to test all the ivars, or can it return early?

    • Discussed comparison with MPI_Testsome

    • Post-call update: MPI 3.1 includes the following note:

      Advice to users. The use of MPI_TESTSOME is likely to be more effcient than the use of MPI_TESTANY. The former returns information on all completed communications, with the latter, a new call is required for each communication that completes.

      This seems to imply that MPI_Testsome does test all the request handles, but it will not block if none are complete (cf. MPI_Waitsome).