February 2016 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] MPI_T question about cvar value guarantees
by Schulz, Martin 05 Feb '16

05 Feb '16

Yes, I agree, we should probably submit an errata for this text. Martin On 2/5/16, 4:50 PM, "mpiwg-tools on behalf of Jeff Squyres (jsquyres)" <mpiwg-tools-bounces(a)lists.mpi-forum.org on behalf of jsquyres(a)cisco.com> wrote: >> On Feb 5, 2016, at 4:26 PM, Schulz, Martin <schulz6(a)llnl.gov> wrote: >> >> That¹s a good question and I don¹t think we say - my original intent >>when >> writing the document (based on my personal model that I had in my head >>for >> this) was to provide no guarantees once MPI_T gets uninitialized, so in >> this case both versions would be OK. In fact, it could be even worse - >> what happens in case 1 if the component is not reloaded? Do you still >>have >> access to the variable at all? This is probably more likely if the MPI_T >> only block is after MPI_Finalize (since this would unload components), >>but >> the principle is the same. >> >> For the discovery/query routines we state that the numbering is not >> allowed to change between ³runs², which may have been the wrong thing to >> say - it probably should say ³while MPI_T is initialized². In this case, >> there would really not be any guarantees at all. If you wanted >>guarantees, >> you would have to keep MPI_T initialized. > >That sounds fine to me. I think that this is worth an errata. > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://secure-web.cisco.com/1YQzVZ9p1gLekoVYv9VGQ_-CNEYsPlQQtkva9wBeUEuV5I >NONI4Nm-vTVCCxm4xjArNq97pldPUVCOWShL7-hhjDh_0uYjZ9MYdA28tvg1pIvOl8shxbRxZh >3FbapA2wu5Q99HsmgPLjCxBBGktJijRvb9BIcaGKHBzMAFlDIX_mz5BZNMo2JRmvTX1neOfbyF >PTV_rVef2O7blagdgDD7YOeu54XlV9ImkS8qcvLeGLcxfmzeu1pPNMN4IoiiAao7Iz2Xh9y7MM >dtqOZi6XcylO9kxyregmJifR44SqEhZukURI8THsglPLQvSmkYM0iVJuc9ZlEXl9nruau-AFKa >VH8WgAzBQkDzVeG2StEuxo/http%3A%2F%2Flists.mpi-forum.org%2Fmailman%2Flistin >fo.cgi%2Fmpiwg-tools >

1 0

Re: [mpiwg-tools] MPI_T question about cvar value guarantees
by Jeff Squyres (jsquyres) 05 Feb '16

05 Feb '16

> On Feb 5, 2016, at 4:26 PM, Schulz, Martin <schulz6(a)llnl.gov> wrote: > > That¹s a good question and I don¹t think we say - my original intent when > writing the document (based on my personal model that I had in my head for > this) was to provide no guarantees once MPI_T gets uninitialized, so in > this case both versions would be OK. In fact, it could be even worse - > what happens in case 1 if the component is not reloaded? Do you still have > access to the variable at all? This is probably more likely if the MPI_T > only block is after MPI_Finalize (since this would unload components), but > the principle is the same. > > For the discovery/query routines we state that the numbering is not > allowed to change between ³runs², which may have been the wrong thing to > say - it probably should say ³while MPI_T is initialized². In this case, > there would really not be any guarantees at all. If you wanted guarantees, > you would have to keep MPI_T initialized. That sounds fine to me. I think that this is worth an errata. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-tools] MPI_T question about cvar value guarantees
by Schulz, Martin 05 Feb '16

05 Feb '16

Hi Jeff, That¹s a good question and I don¹t think we say - my original intent when writing the document (based on my personal model that I had in my head for this) was to provide no guarantees once MPI_T gets uninitialized, so in this case both versions would be OK. In fact, it could be even worse - what happens in case 1 if the component is not reloaded? Do you still have access to the variable at all? This is probably more likely if the MPI_T only block is after MPI_Finalize (since this would unload components), but the principle is the same. For the discovery/query routines we state that the numbering is not allowed to change between ³runs², which may have been the wrong thing to say - it probably should say ³while MPI_T is initialized². In this case, there would really not be any guarantees at all. If you wanted guarantees, you would have to keep MPI_T initialized. Martin On 2/4/16, 10:27 AM, "mpiwg-tools on behalf of Jeff Squyres (jsquyres)" <mpiwg-tools-bounces(a)lists.mpi-forum.org on behalf of jsquyres(a)cisco.com> wrote: >Nathan Hjelm and I stumbled across a question regarding MPI_T today: what >guarantees does MPI_T provide about control variable values when MPI_T is >finalized and MPI is either not initialized or is finalized? > >For example: > >```C >// Block A >MPI_T_Init(...); >MPI_T_Cvar_read(..., &value_pre); >MPI_T_Cvar_write(...); >MPI_T_Finalize(...); > >// ...dead zone where neither MPI_T nor MPI are initialized... > >// Block B >MPI_Init(...) >MPI_T_Init(...); >MPI_T_Cvar_read(..., &value_post); >assert(value_pre == value_post); >``` > >Is it guaranteed that the assert() in block B must be true? > >Here's why I ask -- consider the following two scenarios: > >SCENARIO 1: >=========== > >- Block A causes a dynamically-loaded component to be loaded and >initialized >- The cvar from that dynamically-loaded component is set to a default >value >- The cvar is then read into value_pre >- The cvar is then assigned a non-default value >- MPI_T is then finalized >- Since MPI is not initialized, the dynamically-loaded component is >unloaded (so that the process can be valgrind clean if it exits) > >- Block B causes the same dynamically-loaded component to be loaded and >initialized >- The cvar from that dynamically-loaded component is set to a default >value >- The cvar is then read into value_post >- value_pre and value_post are both the same (default) value -- the >assert passes > >SCENARIO 2: >=========== >- Block A causes a statically-loaded component to be initialized >- The cvar from that statically-loaded component is set to a default value >- The cvar is then read into value_pre >- The cvar is then assigned a non-default value >- MPI_T is then finalized >- Since the component is static, it is *not* unloaded > >- Block B causes nothing to happen to the component (because it's >statically loaded) >- The cvar from that statically-loaded component ***is still set to the >non-default value*** >- The cvar is then read into value_post >- value_pre and value_post are different values -- the assert fails > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://secure-web.cisco.com/1aYzk-C-pCKNMQorT9movJTtkDY_ZUa-l013Nc9x39G_dN >8qgUnFHdDDR2iuEiqxqpenHlCbnU-gvFtVLv6DIaANXPqZzyCRSClVaH6ZZEc0BjHPubzQKiTZ >kShXPFRq7klwIdC3WFLfFFLsxo-2KCdhcWcWkw6hXAz_UqM7CQ12ys4IZabBMsdbIIFYesP_4o >LNkoP_vmozJt34VHZrjefSoaEKvB-Gnfp9011IG_hOPlq75V_kNb5T820AfDVYFHQRnAeCsw-4 >V_HqcX7AsIZEH1ura5UQdgP1Hba8zXL4aekNKNX9BfzgM1zVhVJGc87Esa5UDygPARLatnryLQ >QpRzO4_m99ir8nC-C6zZY8/http%3A%2F%2Flists.mpi-forum.org%2Fmailman%2Flistin >fo.cgi%2Fmpiwg-tools >

1 0

MPI_T question about cvar value guarantees
by Jeff Squyres (jsquyres) 04 Feb '16

04 Feb '16

Nathan Hjelm and I stumbled across a question regarding MPI_T today: what guarantees does MPI_T provide about control variable values when MPI_T is finalized and MPI is either not initialized or is finalized? For example: ```C // Block A MPI_T_Init(...); MPI_T_Cvar_read(..., &value_pre); MPI_T_Cvar_write(...); MPI_T_Finalize(...); // ...dead zone where neither MPI_T nor MPI are initialized... // Block B MPI_Init(...) MPI_T_Init(...); MPI_T_Cvar_read(..., &value_post); assert(value_pre == value_post); ``` Is it guaranteed that the assert() in block B must be true? Here's why I ask -- consider the following two scenarios: SCENARIO 1: =========== - Block A causes a dynamically-loaded component to be loaded and initialized - The cvar from that dynamically-loaded component is set to a default value - The cvar is then read into value_pre - The cvar is then assigned a non-default value - MPI_T is then finalized - Since MPI is not initialized, the dynamically-loaded component is unloaded (so that the process can be valgrind clean if it exits) - Block B causes the same dynamically-loaded component to be loaded and initialized - The cvar from that dynamically-loaded component is set to a default value - The cvar is then read into value_post - value_pre and value_post are both the same (default) value -- the assert passes SCENARIO 2: =========== - Block A causes a statically-loaded component to be initialized - The cvar from that statically-loaded component is set to a default value - The cvar is then read into value_pre - The cvar is then assigned a non-default value - MPI_T is then finalized - Since the component is static, it is *not* unloaded - Block B causes nothing to happen to the component (because it's statically loaded) - The cvar from that statically-loaded component ***is still set to the non-default value*** - The cvar is then read into value_post - value_pre and value_post are different values -- the assert fails -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0