[MPICH] A doubt regarding the manner in the which MPI_init works

[Dave Goodell]

The environment variables used to control debug messages can be found  
here: http://wiki.mcs.anl.gov/mpich2/index.php/Event_Logging

-Dave

On Jan 21, 2008, at 6:54 PM, William Gropp wrote:

> When debugging is enabled by configuring with the appropriate  
> switches, it just causes the appropriate code to be compiled into  
> MPICH2.  There are environment variables and command line options  
> that update the value of MPIU_DBG_ActiveClasses, thus enabling some  
> or all of the debug statements.  As the purpose of these debug  
> statements is primarily to generate output that traces the  
> execution, the ActiveClasses variable allows the user to select  
> which types of debug messages are desired.
>
> Object_set_ref is itself a macro that permits the use of assembly  
> instructions when needed in a multithreaded environment (and one  
> that uses fine-grain locking).  All that it is doing is setting the  
> reference count on the object to the requested value (typically 1  
> or 2, depending on the object).
>
> Bill
>
> On Jan 21, 2008, at 11:37 AM, Krishna Chaitanya wrote:
>
>> Dear Sir,
>> Sorry for the delay.
>> I added a few print statements and took a closer look at the  
>> functions MPIU_DBG_MSG_FMT() and  MPIU_DBG_Outevent (). It turns  
>> out that the MPIU_DBG_ActiveClasses parameter remains at 0 for the  
>> entire program execution, which means, the if() test fails and the  
>> MPIU_DBG_Outevent function never gets called. So, the call to  
>> MPIU_Object_set_ref()  that is being called from MPIR_Init_thread 
>> () is not doing anything in terms of updating or maintaining the  
>> internal data structures.Am I missing something,here?  Could some  
>> one help me out  by explaining this? I hope I have explained my  
>> doubt clearly.
>>
>> Thanks,
>> Krishna Chaitanya
>>
>> On Jan 16, 2008 3:14 AM, William Gropp <gropp at mcs.anl.gov> wrote:
>> Most of the operations that are used as macros are defined that  
>> way so that they can be eliminated at compile time.  The MPIU_DBG  
>> routines are a good example.  These are macros that are used to  
>> enable various debugging options and are not core parts of the  
>> communicator structure.  In fact, when MPICH2 is built for use in  
>> production, these macros are defined as empty.
>>
>> To answer your other question, there are no universally used  
>> routines for list management - instead, different modules make use  
>> of the routines that they need.
>>
>> Bill
>>
>> On Jan 15, 2008, at 2:25 PM, Krishna Chaitanya wrote:
>>
>>> Dear All,
>>>              I have been trying to understand the types of data  
>>> structures used by MPICH2 and the way in which the various lists  
>>> are maintained and how they are initialized. I happen to observe  
>>> that most of such routines have been implemented as macros which  
>>> has made my job slightly harder as they dont appear while  
>>> debugging with gdb.( Is there a way to trace through them at run  
>>> time?)
>>>
>>>              For example, I was keen on observing how MPICH2  
>>> deals with the MPI_COMM_WORLD data structure, which is of type  
>>> MPID_COMM and it is a member of MPICH_PerProcess_t. So, at the  
>>> time of populating  this structure , the library calls  [ from  
>>> MPIR_Init_thread(...)    ]
>>>          MPIU_Object_set_ref( MPIR_Process.comm_world, 1 );
>>>          -- >   MPIU_DBG_MSG_FM ( .... )
>>>                   -- > MPIU_DBG_MSG_FMT ( .. )
>>>                          -- >  MPIU_DBG_Outevent ( ... )
>>>                                  --> va_start and other such list  
>>> related macros.
>>>
>>> However, when the MPIU_DBG_Outevent function is invoked, the  
>>> paramater, int kind is hard-coded to be 0. When the kind value is  
>>> zero, the library does not do any list related work.Instead, it  
>>> prints some details into a file.  So, how does the MPICH library  
>>> maintain reference to the  MPIR_Process.comm_world structure,  
>>> without the invocation of macros like va_start, va_arg etc.
>>>
>>> Its quite possible that I have got things wrong as I am jumping  
>>> from one function to another using the ctags and I havent  
>>> actually seen the code behave as above during run-time as we are  
>>> dealing with macros. So, please correct me if I have got  
>>> something wrong.
>>>
>>> And, I am trying to draw an analogy between the OPEN-MPI and the  
>>> MPICH2 when it comes to the way the internal data structures are  
>>> handled. In Open-MPI, the OPAL library maitains such lists and  
>>> has routines to manipulate them. Does MPICH have any other way of  
>>> working with the lists of objects other than using the va_start  
>>> and other related macros?
>>>
>>> NOTE :  I am using the mpich2-1.0.6 version.
>>>
>>> Thanks,
>>> Krishna Chaitanya K,
>>> National Institute of Technology,Karnataka ( NITK)
>>> India.
>>> -- 
>>> In the middle of difficulty, lies opportunity
>>
>> William Gropp
>> Paul and Cynthia Saylor Professor of Computer Science
>> University of Illinois Urbana-Champaign
>>
>>
>>
>>
>>
>> -- 
>> In the middle of difficulty, lies opportunity
>
> William Gropp
> Paul and Cynthia Saylor Professor of Computer Science
> University of Illinois Urbana-Champaign
>
>