Subject: Proposals for MPI_GET_TAG, SOURCE, COUNT.

From: William Gropp <[email-masked]>
Date: Fri, 17 Dec 93 14:07:10 CST

Problems with the current specification:

I. Excessive function calls in Fortran

Suggested solutions:

Make layout of MPI_Status visible to user

    Fortran:

    INTEGER MPI_STATUS_SOURCE, MPI_STATUS_TAG, MPI_STATUS_COUNT
    PARAMETER(MPI_STATUS_SOURCE=1,MPI_STATUS_TAG=2,MPI_STATUS_COUNT=3)
    INTEGER MPI_STATUS_SIZE
    PARAMETER (MPI_STATUS_SIZE=3)

    C:
    typedef struct {
	int source, tag, count;
	} MPI_Status;

    Version A:
    These are IN ADDITION to MPI_GET_TAG etc.

    Version B:
    These REPLACE MPI_GET_TAG etc.        

Rationale:
MPI_Status already has to be visible to the user since it is allocated by the
user (and there is no MPI_CREATE_STATUS routine).  The function versions,
while reasonable in C because they can easily be implemented as macros, cause
potential difficulties for Fortran users.  In addition, being able to do
"switch (status.tag)" is convenient.  We believe no generality is lost in
taking this approach (again because MPI_Status is user-allocated). 

II. MPI_GET_COUNT has a datatype parameter

This is needed only when used on a status returned by a probe.  In othercases,
the datatype would have been supplied on the RECEIVE/WAIT that returned the
status.

Suggested solutions:

Have MPI_GET_COUNT (for receive) and MPI_GET_PROBE_COUNT (for probe).

    MPI_GET_COUNT( MPI_Status status, int *count )

    MPI_GET_PROBE_COUNT( MPI_Status status, MPI_Datatype datatype, int *count )

(If MPI_GET_COUNT called with a status returned from a probe, the results
are the same as MPI_GET_PROBE_COUNT( status, MPI_BYTE, count ).)

Note that if I.B is accepted, MPI_GET_COUNT disappears but MPI_GET_PROBE_COUNT
remains as a routine (that can be implemented as a macro, but because of the
potential complexity in handling datatype, probably will not be).

Rationale:
The datatype argument to MPI_GET_COUNT is either irrelevant (supplied on the
RECEIVE) or essential (status from PROBE); this suggests two different
functions.

Bill and Rusty

---

From: [email-masked] (James Cownie)
Date: Tue, 21 Dec 1993 14:22:33 +0000

Bill suggests making the structure of the status object visible to the
user.

I think this is OK, BUT we need to be very clear that we DON'T specify
the full structure to the user, but only the names of certain fields
she can be guaranteed to access. I strongly expect that I will want to
hide other things in the status as well as the user visible fields.

The Fortran argument is a strong one ! (I had hoped that one could
fudge this using statement functions which are often implemented in a
macro like way, but I don't now believe this is possible).

MPI_GET_COUNT and datatype argument.

As I remember it we went around this a few times... the arguments (I
think) go like this :-

1) we want MPI_GET_COUNT to be the same whether used after probe or
   recv. (we were chopping functions at the time !)
2) we can't assume that the datatype can be saved in recv and used in
   GET_COUNT (because the user could free it in between, and the system
   doesn't have visibility of the status objects).

If we take path 1 and delete all of these functions, then I suppose it
doesn't matter anyway. If we keep them I'd like to only have one
function and leave the arguments the same...

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