[Openshmem-list] Effects of removing implicit finalize from the specification
John C. Linford
jlinford at paratools.com
Tue Mar 21 13:54:28 UTC 2017
Hi Jeff, Naveen,
Tools need some way of querying the init/fini reference counter to
determine when it's actually safe to merge and dump data.
is_{initia,fina}lized() seems like a nice way to expose the counter.
Return values also make sense to me. Is there harm in doing both?
On Tue, Mar 21, 2017 at 12:15 AM, Jeff Hammond <jeff.science at gmail.com>
wrote:
>
>
> 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/
>
> _______________________________________________
> Openshmem-list mailing list
> Openshmem-list at openshmem.org
> http://www.openshmem.org/mailman/listinfo/openshmem-list
>
>
--
John C. Linford, Ph.D.
Senior Computer Scientist
ParaTools, Inc. <http://www.paratools.com>
5520 Research Park Drive, Suite 100
Baltimore, MD 21228
Phone: 540-808-9250
-------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.openshmem.org/pipermail/openshmem-list/attachments/20170321/c32f35b1/attachment.html>
More information about the Openshmem-list
mailing list