Update atomic memory model text #204

jdinan · 2018-02-06T01:16:33Z

Clarify the various cases that violate atomicity. There should be no semantic changes.

Closes #172

Clarify the various cases that violate atomicity. There should be no semantic changes. Signed-off-by: James Dinan <[email protected]>

jdinan · 2018-03-19T17:26:54Z

content/memory_model.tex

+exclusivity when concurrent accesses to the same location are performed using
+\openshmem atomic operations using different datatypes, when non-atomic
+\openshmem operations are used to access the given location, or when
+non-\openshmem operations are performed on the given location.  The result in


Add: "(e.g. load and store operations)"

jdinan · 2018-03-19T17:34:20Z

content/memory_model.tex

+concurrent accesses to the same location by \openshmem atomic operations using
+the same datatype will be exclusive.  However, they do not guarantee
+exclusivity when concurrent accesses to the same location are performed using
+\openshmem atomic operations using different datatypes, when non-atomic


Add wait/test with same datatype

@jdinan, you mean to add wait/test with same datatype to the allowed/defined list, correct?

jdinan · 2018-03-19T17:42:37Z

content/memory_model.tex

-outside.
+\openshmem contains a number of routines that perform atomic operations on
+symmetric data objects (Section \ref{sec:amo}).  These routines guarantee that
+concurrent accesses to the same location by \openshmem atomic operations using


Add: "and atomic-compatible operations"?

jdinan · 2018-03-19T17:43:16Z

content/memory_model.tex

+\openshmem contains a number of routines that perform atomic operations on
+symmetric data objects (Section \ref{sec:amo}).  These routines guarantee that
+concurrent accesses to the same location by \openshmem atomic operations using
+the same datatype will be exclusive.  However, they do not guarantee


Instead of "datatype" reference the table in the AMO section and use consistent terminology.

Signed-off-by: James Dinan <[email protected]>

jdinan · 2018-04-26T20:58:17Z

Requesting committee feedback on the updated draft: osh-6ad7676.pdf.
Flagged reviewers: @shamisp, @spotluri, @manjugv, @npark

jdinan · 2018-05-21T18:40:14Z

Feedback from May 21 reading:

Follow up with @manjugv about shmem_barrier / interprocess synchronization in concurrency definition.
Examples: add comment above each incorrect line of code to clarify that it causes undefined behavior
Example 3: Look into using C11 atomic operation (is the type compatible with SHMEM operations?)

jdinan · 2018-05-29T19:09:36Z

C11 specifies that "The size, representation, and alignment of an atomic type need not be the same as those of the corresponding unqualified type." OpenSHMEM operations on such types are therefore not well-defined, so C11 atomics won't work in example 3.

Signed-off-by: James Dinan <[email protected]>

jdinan · 2018-07-03T16:55:40Z

Special ballot changes: 252a6a1 and 04a876d

anshumang · 2018-07-23T16:06:12Z

content/memory_model.tex

+Section~\ref{subsec:p2p_intro}.  The atomic and atomic compatible routines
+guarantee that concurrent accesses by any of these routines to the same
+location and using the same datatype (specified in Tables~\ref{stdamotypes} and
+\ref{extamotypes}) will be exclusive.  In contrast to atomic operations, atomic


short and unsigned short is supported by wait_until (not supported in amotypes); float and double are the other non-overlapping types.

This text is intended to specify semantics for atomics, so those types shouldn't really come into play. But, I see your point that as it's written, it also specifies semantics for overlapping wait operations without atomics. How about splitting these cases up:

The atomic routines guarantee that concurrent accesses by any of these routines to the same location and using the same datatype (specified in Tables~\ref{stdamotypes} and \ref{extamotypes}) will be exclusive. Similarly, concurrent accesses by atomic and atomic compatible routines to the same location and using the same datatype will also be exclusive.

Follow-up question : will there be a usecase for short and unsigned short if the amo APIs end up being the only way to signal wait_until?

IIRC, InfiniBand doesn't have hardware support for 8- and 16-bit atomics. That's one argument in favor supporting scalar put with the wait operations..

manjugv · 2018-07-23T20:34:35Z

July 23rd Meeting Notes: Ballot postponed

BryantLam · 2018-07-23T23:50:23Z

Atomic completion of `shmem_wait_until`

@shamisp expressed concern that shmem_wait_until is not efficiently implementable if it is to both guarantee atomic and non-atomic completion. He claimed shmem_wait_until should only work on non-atomic operations or only on atomic operations, but not both.

OpenSHMEM 1.4 already specifies that atomic and non-atomic completion can be achieved with shmem_wait_until:

shmem_wait and shmem_wait_until wait for ivar to be changed by a write or an atomic operation issued by a PE. ...

Note to implementors -- Implementations must ensure that shmem_wait and shmem_wait_until do not return before the update of the memory indicated by ivar is fully complete. Partial updates to the memory must not cause shmem_wait or shmem_wait_until to return.

This led into a discussion about whether the semantics for wait-until are effectively broken.

Definition of concurrent

04a876d specifies generic statements on concurrency that could apply to elsewhere in the document. One suggestion was to move this definition to a higher level/another section and simply reference it here.

jdinan · 2018-07-26T15:39:56Z

@shamisp @BryantLam Let's discuss this at the next RMA WG meeting. The purpose of this ticket is only to clarify existing semantics (broken or not). Restricting the behavior of shmem_wait is being pursued in separate proposal led by @anshumang and @spotluri. One of the goals of this ticket was to raise awareness of this issue; glad it's working.

I'm fine with moving the concurrency definition to a terms section. Can we handle this separately as part of #228?

manjugv · 2018-07-26T18:25:00Z

I'm fine with moving the concurrency definition to a terms section. Can we handle this separately as part of #228?

Agree with this. As I mentioned on the call, we need to converge this definition with what @anshumang and @spotluri are proposing in #232 and #233 .

jdinan · 2018-07-26T20:46:14Z

@manjugv Which definition are you referring to? The definition of concurrency?

Update: I see #229 mentions incorporating this definition for concurrency. Given that the memory model has not yet gelled, I'd like to suggest ratifying/merging this ticket to close out these changes and allow that ticket to integrate them in time for their reading.

Signed-off-by: James Dinan <[email protected]>

shamisp · 2018-08-01T19:09:06Z

@jdinan I see it as an integral part of memory model.

jdinan · 2018-08-01T21:35:43Z

@shamisp Can you spot me a couple more words? I'm not sure how to interpret your feedback, and github comments are wonderfully context-free.

jdinan · 2018-08-02T19:24:43Z

Feedback from Aug. 2 WG meeting: remove concurrency definition and atomic compatible; handle these as part of the memory model proposal.

To be handled in a future proposal. Signed-off-by: James Dinan <[email protected]>

jdinan · 2018-08-02T19:58:26Z

BTW, the "left shift" comment in example 1 strikes me as questionable advice given that the original code has different behaviors depending on the endianness of the system it's running on. Do we want to change that bit to something like: "For example, the 32-bit value can be left-shifted and a 64-bit atomic OR operation can be used."?

jdinan · 2018-08-07T16:05:54Z

Special ballot changes: 252a6a1, 04a876d, 12e0687, and b3b5cfb.

Combined diff of special ballot changes

shamisp · 2018-08-10T18:34:30Z

@jdinan looks good to me.

Update atomic memory model text

902ee61

Clarify the various cases that violate atomicity. There should be no semantic changes. Signed-off-by: James Dinan <[email protected]>

jdinan added this to the OpenSHMEM 1.5 milestone Feb 6, 2018

jdinan self-assigned this Feb 6, 2018

jdinan requested a review from RaymondMichael February 6, 2018 01:16

RaymondMichael approved these changes Feb 6, 2018

View reviewed changes

jdinan added the PendingReading label Feb 6, 2018

jdinan commented Mar 19, 2018

View reviewed changes

Update atomic mem model text and add anti-examples

6ad7676

Signed-off-by: James Dinan <[email protected]>

jdinan added PendingReading and removed PendingReading labels May 7, 2018

jdinan added the HadReading label May 21, 2018

Add 'undefined behavior' comments to AMO examples

617b2d4

Signed-off-by: James Dinan <[email protected]>

jdinan added PendingBallot SpecialBallot and removed PendingReading labels May 29, 2018

James Dinan added 3 commits May 31, 2018 10:38

Merge branch 'master' into pr/atomicity-clarification

18c8ea8

Add changelog entry

252a6a1

Signed-off-by: James Dinan <[email protected]>

Atomic memory model updates from May 21 reading

04a876d

Signed-off-by: James Dinan <[email protected]>

anshumang reviewed Jul 23, 2018

View reviewed changes

anshumang mentioned this pull request Jul 23, 2018

Memory model umbrella ticket #229

Open

nspark mentioned this pull request Jul 24, 2018

Add support for put with signal operation #218

Closed

Avoid specifying behavior for concurrent atomic compatible ops only

12e0687

Signed-off-by: James Dinan <[email protected]>

Remove concurrency and atomic compatiblity

b3b5cfb

To be handled in a future proposal. Signed-off-by: James Dinan <[email protected]>

jdinan added Ratified SpecialBallotAccepted labels Aug 23, 2018

jdinan merged commit 973ab5c into openshmem-org:master Aug 23, 2018

jdinan deleted the pr/atomicity-clarification branch September 11, 2018 14:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update atomic memory model text #204

Update atomic memory model text #204

jdinan commented Feb 6, 2018

jdinan Mar 19, 2018

jdinan Mar 19, 2018

spotluri Apr 11, 2018

jdinan Mar 19, 2018

jdinan Mar 19, 2018

jdinan commented Apr 26, 2018

jdinan commented May 21, 2018

jdinan commented May 29, 2018

jdinan commented Jul 3, 2018

anshumang Jul 23, 2018

jdinan Jul 26, 2018

anshumang Jul 26, 2018

jdinan Jul 26, 2018

manjugv commented Jul 23, 2018

BryantLam commented Jul 23, 2018

jdinan commented Jul 26, 2018 •

edited

Loading

manjugv commented Jul 26, 2018

jdinan commented Jul 26, 2018 •

edited

Loading

shamisp commented Aug 1, 2018

jdinan commented Aug 1, 2018

jdinan commented Aug 2, 2018

jdinan commented Aug 2, 2018

jdinan commented Aug 7, 2018 •

edited

Loading

shamisp commented Aug 10, 2018

Update atomic memory model text #204

Update atomic memory model text #204

Conversation

jdinan commented Feb 6, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jdinan commented Apr 26, 2018

jdinan commented May 21, 2018

jdinan commented May 29, 2018

jdinan commented Jul 3, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

manjugv commented Jul 23, 2018

BryantLam commented Jul 23, 2018

Atomic completion of shmem_wait_until

Definition of concurrent

jdinan commented Jul 26, 2018 • edited Loading

manjugv commented Jul 26, 2018

jdinan commented Jul 26, 2018 • edited Loading

shamisp commented Aug 1, 2018

jdinan commented Aug 1, 2018

jdinan commented Aug 2, 2018

jdinan commented Aug 2, 2018

jdinan commented Aug 7, 2018 • edited Loading

shamisp commented Aug 10, 2018

Atomic completion of `shmem_wait_until`

jdinan commented Jul 26, 2018 •

edited

Loading

jdinan commented Jul 26, 2018 •

edited

Loading

jdinan commented Aug 7, 2018 •

edited

Loading