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

[Naveen Ravichandrasekaran]

Hi Jeff,

> We either need to allow multiple calls to initialize/finalize or we
> need to have is_initialized/is_finalized queries.  MPI does the latter
> but since it is utterly trivial to ref count in this case, we should just
> do better than MPI and do the former.

My requirement is not to support multiple shmem_finalize calls. I was just
merely stating the fact that the side-effect of implicit finalize in the current
specification allows the usage of shmem_finalize multiple times.

What we really need is a semantics which successfully performs finalize or
do no-op when the user uses atexit(shmem_finalize) in their application.

shmem_init(); /* ref_count++ -> actual initialization */
shmem_init(); /* ref_count++ -> no-op */
shmem_finalize(); /* ref_count-- -> no-op */
shmem_finalize(); /* ref_count-- -> actual finalization */

FWIU, the reference counter method would be useful for handling
multiple shmem_init and shmem_finalize calls, but it won’t probably
work for handling atexit(shmem_finalize).

In this example, it is unclear how the reference counter works.
int main(void) {
        shmem_init();          /* ref_count++ -> actual initialization */
        atexit(shmem_finalize);
        shmem_finalize();   /* ref_count-- -> actual finalization */
        return 0;                      /* unclear what should happen here */
}

Irrespective of the number of times shmem_init is used, we need to
successfully handle atexit(shmem_finalize). So, I would prefer adding
new APIs in SHMEM to query is_initialized/is_finalized and let the
users handle atexit(shmem_finalize) scenario correctly.

-Naveen N Ravi.

From: Jeff Hammond [mailto:jeff.science at gmail.com]
Sent: Monday, March 20, 2017 4:01 PM
To: Naveen Ravichandrasekaran <nravi at cray.com>
Cc: openshmem-list at openshmem.org
Subject: Re: [Openshmem-list] Effects of removing implicit finalize from the specification

If we permit multiple calls to finalize then we should also permit multiple calls to initialize.  This makes it easy on applications that use libraries and the libraries do not know whether they should call initialize or not.

We either need to allow multiple calls to initialize/finalize or we need to have is_initialized/is_finalized queries.  MPI does the latter but since it is utterly trivial to ref count in this case, we should just do better than MPI and do the former.

We could add return codes on initialize/finalize to allow users to know whether the calls were no-ops or not.  This does not break any existing code because users do not have to assign return codes to variables.

Jeff

On Mon, Mar 20, 2017 at 1:37 PM, Naveen Ravichandrasekaran <nravi at cray.com<mailto: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<mailto:Openshmem-list at openshmem.org>
http://www.openshmem.org/mailman/listinfo/openshmem-list



--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.openshmem.org/pipermail/openshmem-list/attachments/20170321/efe73777/attachment-0001.html>