Threads WG Meeting 9 17 2019

Participants: Manju, Dave, Min, Naveen, Bryant(?)

Agenda

Continue reading for MPI and OpenSHMEM Interoperability proposal

• Proposal PR: https://github.com/minsii/openshmem-specification/pull/2
• Slides (for thread safety discussion): https://anl.box.com/s/g5vwntai5jt8y6xz7qp43hityhwxqum6

Note

• Section 1.6:
  • add context to connect the paragraph (where we say we do not support progress for MPI) and the note to implementors (where we say we should support in implementations).
• Section 2.1:
  • Can we call the query API before init and have a new query property SHMEM_SUPPORT_MPI ?
    • It might be better to define it in vendor's doc. Because it relies on how the user compiles the program (e.g., SOS does not support it, but the user may link with an external MPI library), so the return value from the SHMEM runtime (e.g., SOS) will not be meaningful.
• Thread safety issues:
  • THREAD_SINGLE: the clarification may or may not be needed. But we can add it in the proposal.
  • THREAD_FUNNELED|THREAD_SERIALIZED:
    • The later approach (i.e., require the user program to ensure single thread access to SHMEM and MPI in the hybrid program) is easier to current SHMEM implementations.
    • So far, we do not have a real user example using two threads for SHMEM and MPI but with FUNNELDED|SERIALIZED safety (it might give better performance if the underlying runtime does not have any shared resources between SHMEM and MPI).
    • Will go with the later approach in this proposal for simplicity