"Note to Implementers" in shmem_wait_until

[naveen-rn]

We have the following Notes to Implementers in the shmem_wait_until routine:

Note to implementers Some platforms may allow wait operations to efficiently poll or block on an update to ivar. On others, an atomic read operation may be needed to observe updates to ivar. On platforms where atomic read opera- tions incur high overhead, implementations may be able to reduce the number of atomic reads performed by using non-atomic reads of ivar to wait for a change to occur, followed by an atomic read operation to fetch the updated value.

I assume this is in general to all the wait operations, should we remove this from the shmem_wait_until and add it in the general point-to-point synchronization section?

[naveen-rn]

@nspark @BryantLam @davidozog - any comments

[davidozog]

Thanks for catching this @naveen-rn. I don't believe it crossed my mind to include it while proposing the multi-element wait/test routines. I would approve moving this up to the section overview since it applies to all p2p sync routines.

Side note: If we do that, I presume it could retain the "Note to Implementers" title? It's definitely a note to implementers, and we do have (a little?) precedent for "Note to Implementers" in overview sections (see "Progress of OpenSHMEM Operations" and "Interoperability" initialization section).

[jdinan]

It could read a bit odd to have a note to implementors before the functions themselves have been described. If it's weird, then I would suggest leaving this note in its current location.

[naveen-rn]

Should we slightly modify the text as follows:

Current version:

Note to implementers Some platforms may allow wait operations to efficiently poll or block on an update to ivar. On others, an atomic read operation may be needed to observe updates to ivar. On platforms where atomic read opera- tions incur high overhead, implementations may be able to reduce the number of atomic reads performed by using non-atomic reads of ivar to wait for a change to occur, followed by an atomic read operation to fetch the updated value.

Requested modification:

Note to implementers Some platforms may allow wait operations to efficiently poll or block on an update to ivar. On others, an atomic read operation may be needed to observe updates to ivar. On platforms where atomic read operations incur high overhead, implementations may be able to reduce the number of atomic reads performed by using non-atomic reads of ivar to wait for a change to occur, followed by an atomic read operation to fetch the updated value until the synchronization condition is satisfied.

I'm fine without this change. Its just a added clarification, if required.