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

Jeff Hammond jeff.science at gmail.com
Mon Mar 20 21:00:33 UTC 2017


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>
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
>



-- 
Jeff Hammond
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/20170320/191975ce/attachment.html>


More information about the Openshmem-list mailing list