RMA WG 08 16 2018

Agenda

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.

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.

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?

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).