[Openshmem-list] Effects of removing implicit finalize from the specification

Nicholas Park nspark at computer.org
Tue Mar 21 21:33:06 UTC 2017


As I understand this PR, the intent is to define a valid OpenSHMEM program
to the following two cases (for now, pending discussion on multiple
init/finalize):

// Legacy (deprecated) behavior
int main(void) {
  start_pes(0);
  return 0; // includes "implicit finalize"
}

// Desired behavior
int main(void) {
  shmem_init();
  shmem_finalize();
  return 0;
}

The specification currently says:

> After the first call to shmem_init, a subsequent call to shmem_init in the
> same program results in undefined behavior.
>
and this PR does not change that.

The specification does not identify multiple calls to shmem_finalize() as
erroneous, but also does not guarantee that shmem_finalize() may be called
more than once. Given its behavioral description, I would expect that
multiple calls to shmem_finalize() are erroneous.

The one exception is in the interpretation of implicit finalize that I
understand this PR intends to correct. That is, as of 1.3, I think some
implementations support your Example #3 because the specification was
under-specified.

Nick

On Mon, Mar 20, 2017 at 4:37 PM, Naveen Ravichandrasekaran <nravi at cray.com>
wrote:

> At present, the specification allows the multiple usage of shmem_finalize.
> This seems to be a defined behavior and multiple subsequent calls to
> finalize
> are no-ops.
>
> The following example should pass as per the current specification;
>
> Example:1
> int main(void) {
>         shmem_init();
>         shmem_finalize();
>         shmem_finalize();
>         return 0;
> }
>
> In Example:1, we have three finalize (2 explicit + 1 implicit) operations.
> Even any common SHMEM usage, will have two finalize operations
> (1 explicit + 1 implicit). Even though the specification is not clear
> about the
> above usage, this is the side-effect of having implicit finalize at exit()
> or at
> return from main.
>
> Example:2
> int main(void) {
>         shmem_init();
>         atexit(shmem_finalize);
>         return 0;
> }
>
> During F2F meeting, we decided to drop implicit finalize in the
> specification.
> The argument was that the users can explicitly call "atexit" in the
> application
> to achieve the above behavior as shown in Example:2.
>
> Example:3
> int main(void) {
>         shmem_init();
>         atexit(shmem_finalize);
>         shmem_finalize();
>         return 0;
> }
>
> FWIU, if we remove implicit finalize from the specification - Example:2 is
> guaranteed to work but the behavior on Example:3 is undefined.
>
> To allow the explicit atexit usage, we either
> 1. Need to specify that multiple calls to finalize are no-ops or
> 2. We need to have a new API - "shmem_finalized()" so that the users can
> have a wrapper from atexit which checks shmem_finalized() before calling
> shmem_finalize().
>
> Please let me know, if this analysis looks valid.
>
> -Naveen N Ravi
>  Cray Inc.
>
> _______________________________________________
> Openshmem-list mailing list
> Openshmem-list at openshmem.org
> http://www.openshmem.org/mailman/listinfo/openshmem-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.openshmem.org/pipermail/openshmem-list/attachments/20170321/9d2f544a/attachment.html>


More information about the Openshmem-list mailing list