Newsgroups: comp.parallel.mpi
From: cameron@epcc.ed.ac.uk (Kenneth Cameron)
Subject: Re: MPI_PROC_NULL and invalid message tags
Organization: Edinburgh Parallel Computing Centre
Date: Sun, 3 Mar 1996 22:27:41 GMT
Message-ID: <DnpqE7.24t.0.staffin.dcs.ed.ac.uk@dcs.ed.ac.uk>

In article <4hb1un$9t3@murrow.corp.sgi.com>, salo@mrjones.engr.sgi.com (Eric Salo) writes:
> > Eric, I would argue for the opposite position.  An MPI program has to be
> > valid first, then we can check for the various special cases within that
> > context.  Similarly, can we give an invalid datatype for a zero-length
> > message?  The behaviour after an erroneous call isn't defined (chap. 2).
> > This can be used to defend this position (giving an invalid argument makes
> > the program erroneous).
> 
> Well, then...
> 
> What about an invalid pointer for a zero-length message?
> 

An interesting feature of the Cray T3D Fortran compiler is that character
arrays are passed as two words, ref + len, not just ref. This causes
later arguments to shifted one place, when an MPI call is make (the
library is writen in C and expects void pointers). Due to the MPI API
taking buffer arguments before datatype arguments, this is expensive
to check. (So we have n't, and character arrays passed to MPI as such
will cause errors).

There is a way this could be fixed. It so happens that valid (data)
addresses, counts, and handles all use distinct ranges of a 64bit word.
We could therefore check that the correct type of arguments are in the right
place and adjust the argument lists when they're not. If any of the
arguments were invalid, even if the nature of the call means that the invalid
argument is not needed within the MPI call, the senario above does suggest
that the conservative interperation of the standard (i.e. that if any argument,
even if the user does not expected it to be needed, is invalid then the call
is erroneous and cannot be expected to succeed) offers the best chance of
portability without compromising performance.

,Kenneth.

-- 
e||) Kenneth Cameron (kenneth@ed)     Edinburgh Parallel Computing Centre e||)
c||c Applications Scientist             University of Edinburgh, Scotland c||c
               This message has been digitally re-mastered.

