Subject: Re: 5184 bottles of sends on the wall...

From: [email-masked] (Al Geist)
Date: Thu, 4 Feb 93 01:29:05 -0500

Steve Otto proposes that the 72 (or 648 if each data type is separate)
sends be matched to the same type of recv.
While I agree with Steve that we will not be able to define much less
test the 5184 combinations if we allow otherwise,
There are obvious cases where the user would want to mismatch send/recv
For example, she may have to do a blocking send, but can get away with
a non-blocking recv. Not all combinations make sense, but
we can't restrict the user to no mismatches.

Al Geist

---

From: [email-masked]
Date: Thu, 4 Feb 1993 08:38:42 +0100

I was glad to read Steve's proposal not to allow mismatches between
different types of sends and receives. If we don't follow that line,
we will most likely cause many problems to the implementors of MPI
which we cannot forsee at the moment. Also, the requirement of matching
sends and receives could be used to check the correct behaviour of the
user program in some debugging mode.
  Al's counter-example of course makes sense, but if you have to use
a blocking send, you can get the same by using the non-blocking version
followed directly by the wait-for-completion. I'm looking forward to
seeing an example where you really need the mismatch.

Rolf

---

From: [email-masked] (John Kapenga)
Date: Thu, 4 Feb 93 03:08:28 EST

Rolf asks --
>  ...

By using the wait_for_completion you never need a blocking send/receive
operation.  The code looks a bit ugly. 

Right now we have to have a "mismatch" because we don't have a
synchronized send/receive pair ;-).
Actually I thought the reason that the synchronized send/recieve
pair was there initially was to help insure correctness in matching
calls, as well as a possible simpler implementation.

john

---

From: [email-masked] (Stephen R. Wheat)
Date: Thu, 4 Feb 93 07:58 MST

as an implementor of blocked and non-blocked messaging systems, I have not
experienced any "system" problems associated with matching mixed send/receives.
While worrying about the "potential" implementation difficulties, I fear
that we make use of the system so difficult that it won't be used (so would
that make it easy to use?).

Furthermore, as for the theme that seems to prevail concerning features that
only "wizards" would use, if we do not provide wizardly type features, then
the wizards will not use MPI.  Then to whom will the "novice" types refer when
they finally see the light of low-performance codes running in a
high-performance compute environment?

Stephen

---

From: [email-masked] (John Kapenga)
Date: Thu, 4 Feb 93 10:22:30 EST

My initial concept of mixing IO types was that blocking
and non-blocking could be freely mixed, but that synchronized
was special and a synchronized send would only match a synchronized
receive. 

The rationale for dropping the synchronized recieve is OK with me.
I have no problems with the current proposal.

Overlappping communication and computation is the only way to get
good prerformance in many applications. It must be assumed to be
the norm rather than the exception. I would not be able to use
a system that did not support it.

john