[mpiwg-tools] MPI_T question about cvar value guarantees

[Schulz, Martin]

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 at lists.mpi-forum.org on behalf of jsquyres at 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 at cisco.com
>For corporate legal information go to:
>http://www.cisco.com/web/about/doing_business/legal/cri/
>
>_______________________________________________
>mpiwg-tools mailing list
>mpiwg-tools at 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
>