Clarify buffer validity requirements for nonblocking RMA

[nspark]

The nonblocking RMA routines say:

shmem_put_nbi The routines return after posting the operation. The operation is considered complete after a subsequent call to shmem_quiet. At the completion of shmem_quiet, the data has been copied into the dest array on the destination PE. [...]

shmem_get_nbi The get routines provide a method for copying a contiguous symmetric data object from a different PE to a contiguous data object on the local PE. The routines return after posting the operation. The operation is considered complete after a subsequent call to shmem_quiet. At the completion of shmem_quiet, the data has been delivered to the `dest array on the local PE

Should we clarify the (implicit) requirement that the local buffer (i.e., dst for get_nbi, src for put_nbi) remain valid until a subsequent shmem_quiet operation?

For example, the following two cases should be invalid:

void error1(void *dst, size_t nbytes, int pe) {
  // src is a VLA whose lifetime is scoped to the function 
  char src[nbytes];
  shmem_putmem_nbi(dst, src, nbytes, pe);
}

void error2(const void *src, size_t nbytes, int pe) {
  // dst will be freed before the get operation completes 
  void *dst = malloc(nbytes);
  shmem_getmem_nbi(dst, src, nbytes, pe);
  free(dst);
}

[manjugv]

@nspark Yes, we should include the verbiage.

[jdinan]

I think this may be easiest to address via the updated Memory Model section in front matter. Assigning to myself to volunteer to draft the relevant text.

[wrrobin]

@jdinan Should this also clarify defining local and remote completion?

[jdinan]

Scratch that, this will go in "Invoking OpenSHMEM Operations" in the Execution Model section.

[jdinan]

@wrrobin The concepts are definitely related. Interested in your feedback on RaymondMichael#26.

[wrrobin]

Thanks @jdinan. This change looks good to me. Do you think we should add/update any texts in Section 9 API descriptions (e.g. shmem_quiet or shmem_fence) to refer to the in use clause mentioned in RaymondMichael#26?

[jdinan]

Those are two of the hardest to edit sections in the spec. But, improvements are always welcome. 😁

[jdinan]

Anything more we want to do on this issue, specifically to address nonblocking operations?

[jdinan]

@wrrobin @nspark Anything more needed on this issue? Anything we might want to address in 1.6 (if so, I would suggest creating a new issue and referencing this one for context)?

[wrrobin]

@jdinan For 1.5, I am ok to close this issue. Regarding 1.6, I was thinking about whether we can utilize the in use clause more frequently throughout the spec instead of keeping it only in one place. This may help to define the local and remote completion that we are trying to add to the glossary.

[jdinan]

@wrrobin We are trying for an empty list of open issues at the next meeting. If you're satisfied that this issue is resolved for 1.5, you can reassign the issue to 1.6 or close it and open a new 1.6 issue.

[naveen-rn]

Not sure why is this open - looks like we fixed it in 1.5 release. @jdinan can you please confirm - whether it is OK to close?