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

[Krishna Chaitanya]

Dear Sir,
             Thanks for the link. Helped clear some of my doubts.
Thanks,
Krishna Chaitanya K

On Jan 22, 2008 7:51 PM, Dave Goodell <goodell at mcs.anl.gov> wrote:

> 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
> >
> >
>
>


-- 
In the middle of difficulty, lies opportunity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20080122/b148b51a/attachment.htm>