- mpiwg-rma - mailman3.cels.anl.gov

Topics for this week's RMA WG?
by Joseph Schuchart 29 Jul '26

29 Jul '26

1 0

No RMA WG meeting today
by Joseph Schuchart 16 Jul '26

16 Jul '26

1 0

No RMA WG today
by Joseph Schuchart 02 Jul '26

02 Jul '26

1 0

RMA WG meeting this week
by Joseph Schuchart 17 Jun '26

17 Jun '26

1 0

Re: [mpiwg-rma] RMA WG meeting this week
by Shinji Sumimoto 04 Jun '26

04 Jun '26

Dear All, Here is a summary of today’s meeting using Zoom hub from the transcript. A number after each sentence can refer the part of the transcript, and it is very helpful. Regards, Shinji. RMA WG 2026-06-05 00:00(GMT+9:00) Key Outcomes The working group resolved critical threading and concurrency semantics for MPI device-side operations. Single-thread operation model adopted: each MPI operation must be issued by a single thread, though multiple threads can issue different operations concurrently 12. Host-device epoch separation enforced: concurrent operations from host and device within the same epoch are now explicitly erroneous, with flash operations also prohibited during concurrent device communication 34. Decisions Made * Threading model: Only a single thread per working group is responsible for issuing each MPI operation; multiple threads may call MPI primitives concurrently to start multiple independent operations 12 * No cooperative primitives: Decided against introducing cooperative versions (like SHMEM/NCCL-style cooperative puts) in current proposal; may revisit as future extension 15 * Thread safety alignment: Device operations always operate in MPI_THREAD_MULTIPLE mode without host-side thread model restrictions 67 * Epoch isolation: It is erroneous to call communication procedures on the same window from both host and device within the same access epoch 38 * Flash semantics: Device-side flush only flushes device-initiated operations; host-side flush must flush both host and device operations using reference counters or completion queue polling 910 * Concurrent flush prohibition: Issuing flush operations on the host concurrent with communication operations on the device is erroneous 4 Technical Clarifications * Memory fence semantics: WinSync should be defined as a memory fence (system fence) on the device, similar to host-side shared memory behavior 1112 * Implementation flexibility: Multiple concurrent puts from different threads may be inefficient depending on implementation (e.g., proxy through host vs. direct memcopy vs. NIC access) 1314 * Race conditions: Same race condition risks exist as on CPU when multiple threads call operations without proper synchronization 1516 * Implementation overhead: Host flush of device operations requires maintaining reference counters in global memory or polling device completion queues 910 Removed Content * "When configured correctly" sentence: Removed as non-transparent and repetitive 17 * Thread restriction paragraph: Removed confusing paragraph about MPI thread model restrictions since device operations don't share synchronization with host 67 * "As if by CPU thread" clause: Removed since windows are now separate and don't share synchronization primitives between host and device 618 Text Revisions * Communication operations bullet expanded to clarify multiple threads can call concurrently to start multiple independent operations 19 * Erroneous condition reworded: "It is erroneous to call communication procedures on the same window from both host and device within the same epoch" 3 * Added separate sentence: "It is erroneous to issue flush operations on the host concurrent with communication operations on a device" 4 Pending Confirmation * Implementation feasibility validation needed for host flush of device operations (reference counter overhead acceptable) 910 * Verification that no epoch manipulation primitives (lock/unlock) are exposed for GPU windows, only flush available 20 Other Updates * Notify proposal status: First reading at forum went well with only minor changes needed; no significant opposition; proceeding to no-no vote 21 * Transcript availability: Joseph will record to cloud for automatic transcription going forward 22 Action Items * Joseph: Review and implement minor changes from Notify proposal forum reading before next meeting 21 * Alex: Update proposal text with agreed threading model clarifications and remove identified confusing paragraphs 219 * Alex: Add concurrent flush prohibition language to proposal 4 Next Meeting Two weeks from current meeting date 4 On 2026/06/04 木曜日 20:52, Joseph Schuchart via mpiwg-rma wrote: > Dear all, We’ll meet again this week Thursday to continue the discussion on device-side RMA and recap the Notified RMA reading at the Forum meeting this week. As always, we’re meeting at 10am US > Central and the connection info is available at > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > This message came from outside your organization. > ZjQcmQRYFpfptBannerEnd > Dear all, > > We’ll meet again this week Thursday to continue the discussion on > device-side RMA and recap the Notified RMA reading at the Forum meeting > this week. > > As always, we’re meeting at 10am US Central and the connection info is > available athttps://urldefense.us/v3/__https://github.com/mpiwg-rma/mpi-standard/wiki…. > > Cheers > Joseph > >  > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi…

1 0

RMA WG meeting this week
by Joseph Schuchart 04 Jun '26

04 Jun '26

1 0

RMA WG meeting this week
by Joseph Schuchart 27 May '26

27 May '26

1 0

No meeting today
by Joseph Schuchart 21 May '26

21 May '26

1 0

No meeting today
by Joseph Schuchart 07 May '26

07 May '26

1 0

Re: [mpiwg-rma] Meeting today
by Joseph Schuchart 23 Apr '26

23 Apr '26

1 0