I think that checking the ERROR field of Status is OK even when no request
hase been completed - please, consider this againg:
"If all the requests in the list are null or *inactive* then the call
returns immediately, with index = MPI UNDEFINED *and* an empty status."
Inactive requests have been defined as requests that are currently not
associated with any ongoing communication and are not null requests.
As to your suggestion - I wish I first check if the call has completed
successfully (i.e. whether the return value is MPI_SUCCESS) and then I would
like to check the index and status (this may be performed in any arbitrary
order). It just seams more reasonable to me to first chech the status,
'cause it means whether the commmunication (no matter which one) has
completed, and only if it is OK should I get interested in which one it is.
----- Original Message -----
From: "Jeff Squyres" <jsquyres_at_[hidden]>
To: "General LAM/MPI mailing list" <lam_at_[hidden]>
Sent: Monday, June 14, 2004 4:29 PM
Subject: Re: LAM: problem with MPI_Waitany
> I believe that the issue is that you are checking the MPI_ERROR field in
> the returned MPI_Status, even when there are no requests to check.
> Specifcally, it looks like your code will call MPI_Waitany() even if both
> the requests have finished already.
>
> While you are correct that this is legal to do (and that there should only
> be *one* MPI_Status), the MPI_Status that is returned in this case is
> meaningless because no communication has completed. Remember that an
> MPI_Status is generated when a non-blocking request has finished -- so you
> can think of it as paired with a specific MPI_Request. In this case,
> there are no requests completed, so the MPI_Status that is returned is
> bogus.
>
> In short, check for index==MPI_UNDEFINED before you check
> status.MPI_ERROR. This should be portable to all MPI implementations.
>
>
> On Mon, 14 Jun 2004, Angel Tsankov wrote:
>
> > Hello!
> >
> > I'm a new user of MPI (and of LAM/MPI). I'm currently implementing a
numerical method in C++ and I have tried some implementations of MPI (for
both linux and win32). In my opinion all of them seem to have different
kinds of problems regarding nonblocking calls. After a couple of days I
managed to isolate a possible problem with MPI_Waitany in the LAM/MPI (LAM
7.0.3/MPI 2 C++/ROMIO). The atachment contains a sample which produces the
following ouput:
> >
> > 0
> > 100a0a98
> > 0
> > 0
> > Error MPI_Error_string: pending request
> >
> >
> > The first 4 lines seem ot be OK, but the last line is the result of
handling an excepiton thrown at line 38. First, I am not quite sure if the
MPI_Waitany func expects a pointer ot a single status or an array of
statuses. Till now my only source of information about MPI is the "MPI: The
complete reference". P.67 says"
> > "MPI WAITANY returns in
> >
> > index the array location of the completed request and returns in status
the status of
> >
> > the completed communication."
> >
> >
> >
> > This should mean that MPI_Waitany expects a pointer to a SINGLE status.
> >
> >
> >
> > Further on, P.86 (section 2.12, ) says
> >
> > "The list of requests passed to MPI WAITANY may contain null or inactive
requests.
> > If some of the requests are active, then the call returns when an active
> >
> > request has completed. If all the requests in the list are null or
inactive then the
> >
> > call returns immediately, with index = MPI UNDEFINED and an empty
status."
> >
> >
> >
> > Other implementations I have tried seem to conform to this behaviour but
I experience other problems with them.
> >
> > If I call the MPI_Waitany func only twice it works fine, i.e. according
to the above description. But calling the func one more time results in the
status object being modified, which is not conformant to the description.
The indes returned is -32766 which looks like MPI_UNDEFINED (I've not
checked to make sure it really is).
> >
> > Anyway, I think I can get around this problem, so I'm just curious if
this is a defect in the implementation or it is standard conformant. In the
latter case I would like to know where I'm wrong.
> >
> >
> >
> > Regards,
> >
> > Angel Tsankov
> >
> >
****************************************************************************
*
> > **
**
> > ** WARNING: This email contains an attachment of a very suspicious
type. **
> > ** You are urged NOT to open this attachment unless you are absolutely
**
> > ** sure it is legitmate. Opening this attachment may cause irreparable
**
> > ** damage to your computer and your files. If you have any questions
**
> > ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING
IT. **
> > **
**
> >
****************************************************************************
*
> >
> >
>
> --
> {+} Jeff Squyres
> {+} jsquyres_at_[hidden]
> {+} http://www.lam-mpi.org/
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
|
