Subject: Mix + Match, NOT

From: [email-masked] (Steve Otto)
Date: Wed, 3 Feb 93 10:31 PST

At first look, I definitely like the proposal of Lusk and Gropp.  
It seems to be the right way to set up a hierarchy of the 1024+ routines 
that we are inventing.

One thing that bothers me:  at the last meeting it was said by several
people that one would be allowed to mix+match different kinds of sends and 
recvs to each other. That is, I could do a "cnsend()" and have that
consumed by a "sbrecvhrr()".  I think we are asking for lots of trouble
if the standard states that this is allowed.  If it is allowed, an
implementor has to worry about 72 x 72 = 5184 different types of
behavior for pt-pt communication.

I don't see a strong reason for allowing mix+match, and on the implementation
side it seems to me that there are many reasons for wanting the
restriction that a send of flavor 53 (out of a possible 72) should
be matched by a recv of the same flavor, 53.  It is true that it seems
like many flavors could be mixed, but consider the synchronization
choices.  If we allow mixing, then the implementor of the sbrecv()
routine has to insure that "sensible" behavior results no matter
what send routine was used.  As I understand it, this means the 
implementation cannot be done in an orthogonal manner.  I'm not
even sure we could define "sensible" for all 5184 combinations!

Comments?  Am I missing something?

--Steve Otto

---

From: [email-masked] (James Cownie)
Date: Thu, 4 Feb 93 12:02:17 GMT

The only place where I can see a need for matching of send and receive
formats is in the heterogeneous case. Here I would be happy to insist
that a heterogeneous send be matched to a heterogeneous receive. 

Since I don't want to enforce in MPI the implemntation decision of
whether the data type conversion occurs at sender or receiver I need
the data type information in both places.

I can see NO reason to restrict any other combinations.

Discussion
----------
There are two major areas which cause the many sends

1) layout of data in store. (contiguous, strided, by iovec)

2) synchronisation behaviour (return asap, return when buffer free,
                              return when data received at other end)

Data layout
-----------
Data layout is an issue which is entirely local. Why does it matter to
the receiver how the sender chose to layout her buffer (or the
converse) ?

This information hiding is one of the things which is an advantage of
message passing.

The data is necessarily serialised to some degree over the
communications medium, so where's the problem ? I believe it is
actually HARDER to insist that the buffer sepcifications match at each
end than not to do this. (Certainly I have to pass additional
information with the message if I'm to check this.)

Synchronisation behaviour
-------------------------
Once again this seems to me to be largely to do with local issues of
buffer management. (Though of course my algorithm may need
certain synchronisation behaviour, in which case I must code it using
the correct forms of send and recv at both ends.)

However I can see no reason to INSIST that the same style of send and
receive is used. Indeed there are strong reasons NOT to do so.

Consider (for example) a server with multiple clients. I'd certainly
like to write it like this :--

	Set up lots of non-blocking receives
	
	while (running)
	{
	    wait for a recv
	    service the request
	    get a reply buffer (may need to wait for one)
	    queue a reply
	    requeue the receive buffer
        }

However the clients can simply make requests thus

	blocking send request
	blocking receive reply

Here is an immediate mismatch in the synchronisations.

-- Jim
James Cownie 
Meiko Limited			Meiko Inc.
650 Aztec West			Reservoir Place
Bristol BS12 4SD		1601 Trapelo Road
England				Waltham
				MA 02154

Phone : +44 454 616171		+1 617 890 7676
FAX   : +44 454 618188		+1 617 890 5042
E-Mail: [email-masked]   or    [email-masked]