Skip to content

RMA WG 08 01 2019

Jump to bottom
Nick Park edited this page Aug 1, 2019 · 2 revisions

Attendees:

  • Jim, Dave, Wasi (Intel)
  • Naveen (Cray)
  • Manju (Mellanox)
  • Akhil (NVIDIA)
  • Nick

Proposal Status Update:

  • Wait-and-test (Jim)
  • Symmetric address clarification (Jim)
    • Naveen: Should put-with-signal include these changes?
      Jim/Dave: This will likely need to be fixed in section committee.
  • Put-with-signal (Naveen)
    • Almost complete, based on latest feedback; fixing minor typos.
    • Will bring for vote on next formal meeting.
    • Future plans: Will add an example as a separate proposal.
  • Nonblocking AMOs (Naveen)
    • Earlier feedback: Define how these operations are different from existing AMOs. Getting support from Manju.
    • Open questions on addressing nonblocking AMOs with shmem_fence and the relaxed ordering of gets proposed by Anshuman.
  • Memory model (Akhil)
    • Akhil is taking over for Anshuman
  • Vector-oriented wait_until/test
    • Successful reading; identified minor issues for special ballot.
    • Nick: Have we discussed adding variants compatible with put-with-signal?
      Dave: Not now, but it would be easy to add in the future if desire arises.
  • Tools proposal (Wasi)
    • Currently identifying types of variables for performance tracking

Discussion

  • Recap of last week's memory model discussion
    • We started last week's discussion with a set of default memory orderings for RMA, AMO, wait/test, fence, and quiet. We wrapped up last week's discussion leaning toward having RMA and AMOs as relaxed, with shmem_fence and shmem_quiet to memory_order_acq_rel and memory_order_seq_cst. It was noted that this notional proposal lacks weaker orderings on fences; e.g., memory_order_acquire and memory_order_release.
    • Should get operations be ordered by shmem_fence? This seems too strong to some, but seems to most closely map shmem_fence to C++'s atomic_thread_fence(memory_order_acq_rel).
    • Suggest defining existing memory model from 1.4. Users may be depending on implicit ordering of blocking operations. A context-specific flag may be one option for providing different implicit ordering models for blocking operations.
    • Goal for concrete review: well-defined model with litmus tests.
Clone this wiki locally