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

[Jeff Hammond]

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

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

Yes, and I think ref_count is the easiest way to achieve that.


> 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
> */
>
> }
>
>
>

It seems perfectly clear to me:

int main(void) {

        shmem_init();          /* ref_count:=1 */

        atexit(shmem_finalize);

        shmem_finalize();   /* ref_count:=0 */

        return 0;                      /* atexit(shmem_finalize) sees that
ref_count=0 and returns immediately */

}



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

Why?  Having is_{initia,fina}lized force the user to do checks that the
implementation can do for them, and I don't see what benefit they provide.

If we add return codes for init and finalize, then users who don't know how
many times init was called can just do this:

int count;
do {
  count = shmem_finalize(); // returns ref_count
  if (count==0) break;
} while (1);


Jeff


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



-- 
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/e5d1376d/attachment.html>