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