[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generalized Request Progress
Title: Re: Generalized Request Progress
Back to the question that started this e-mail trail in the first place. I see what Torsten
(and seems like Rajeev) has asked for is add to MPI the capability of being a general
progress engine – beyond just progressing an MPI’s implementation messaging. I would
ask, why is this preferable to having each library provide it’s own mechanism ? Adding
new generalized capabilities does imply looking at a broad set of potential use cases, to
make sure the solution is general enough to be of broad use.
Rich
On 9/4/07 11:27 AM, "Joachim Worringen" <joachim@xxxxxxxxxxxxxx> wrote:
Hubert Ritzdorf wrote:
> Thus, the behaviour of the MPI implementations which wait for the
> "separate receive complete call"
> (or other MPI communication calls such as MPI_Iprobe or MPI_Test)
> in order to complete the 1st send operation correspond to the MPI
> standard and don't need a fix.
An old topic coming up again and again... To me, it's an indication of
an ambiguity in the standard. Hubert is right with the interpretation of
the part of the standard he has quoted, but there is another part that
is of interest here, namely the progress rule (MPI 1.1, 3.7.4):
"
Progress A call to MPI_WAIT that completes a receive will eventually
terminate and return if a matching send has been started, unless the
send is satisfied by another receive. In particular, if the matching
send is nonblocking, then the receive should complete even if no call is
executed by the sender to complete the send. Similarly, a call to
MPI_WAIT that completes a send will eventually return if a matching
receive has been started, unless the receive is satisfied by another
send, and even if no call is executed to complete the receive.
"
It's necessary to differentiate between (1)"message data completely
placed in user-provided buffer" and (2)"data written into/taken of the
network to avoid blocking". To assert (1), the condition quoted by
Hubert needs to be fulfilled. To assert (2), the progress rule describes
that *starting* the related send/recv operation is sufficient. And a
nonblocking send/recv actually *does* start the operation once it's
matched. Here, Marc is right.
IMHO, the standard needs clarification.
Joachim
--
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com