Skip to content

RMA WG 08 02 2018

Manjunath Gorentla Venkata edited this page Aug 2, 2018 · 4 revisions

Agenda

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

Attendees

  • Intel (Jim, Dave, Wasi)
  • ORNL (Manju)
  • NVIDIA (Anshuman)
  • MTSU (Ferrol)
  • DOD (Nick)
  • Cray (Naveen)
  • Stony Brook (Tony)

Open Action Items

  • None

Action Items

  • None

Notes

Discussion on having a RMA WG meeting at the F2F

——

  • Anshuman to lead the discussion on memory model proposal (tentative) (1hr)

Update on the memory model proposal

——

  • Anshuman created issues on GitHub
  • #229 (Main ticket) covers all issues related to the memory model proposal
  • auxiliary issues are here: #222, #223, and #224

—— Discussion topics : support for nonblocking variant of shmem_put_signal and the atomicity of the signal operation

Naveen : Are we interested in non-blocking variant of put with signal ? Jim and Nick : Yes

Manju : In the proposal, is the signal atomic ? Naveen: Yes Manju: How does the discussion on memory model affect this proposal ? Naveen: We will take this proposal to vote, and reflect the changes that is introduced by the memory model proposal.

—— Discussion topic: Specification meeting feedback

  • Where should we define the concurrent operations?
  • Should we handle the definition of concurrent operation in the memory model ticket?
  • This ticket introduces the semantics that defines the p2p synchronization operations as atomic

Nick’s suggestion: separate the proposal into two tickets (#1) The text that defines concurrent operations, and the semantics that define p2p synchronization operations as atomic (#2) All other text that is acceptable to the committee. Bring the acceptable part (2) of the ticket to committee for reading.

Jim : Agreed

—— Discussion topic: Addressing comments on the GitHub and more

Dave: We don’t want all n-values in the input array ? Should we consider masked array ? Nick : No problem with the masked array. The order of the indices can be left undefined; may be, we can add as a note to the implementers.

Jim: Do you want to return the number of completed operations or should it be returned as a parameter ? Nick : Preference is the return value

Jim: If the user passes the masked array, and all ivars are completed, what do you want to return ?

Nick: Discussion about examples to understand the issues … discussion to continue on the GitHub ..

(Dave please append any notes on this discussion; sorry had to leave)

Clone this wiki locally