RE: [mpi-21] MPI Forum suggestions 11/14

[Erez Haba <erezh@xxxxxxxxxxxxx>]

Such implementations would be really bad for muti-threaded applications, or those using async send. Is there an MPI contract that the application should not access the send buffer for read while the send is not complete?


-----Original Message-----
From: owner-mpi-21@xxxxxxxxxxxxx [mailto:owner-mpi-21@xxxxxxxxxxxxx] On Behalf Of Darius Buntinas
Sent: Friday, November 16, 2007 1:11 PM
To: mpi-21@xxxxxxxxxxxxx
Subject: Re: [mpi-21] MPI Forum suggestions 11/14


I believe the standard allows an implementation to modify the buffer in
a send call, as long as it's changed back before it completes.

I heard (don't remember from who), that there was an implementation that
would do endian conversion in place on the source buffer before sending,
then change it back.

Changing the standard to require the buffer pointer to be const could
theoretically disallow that implementation.  So adding consts wouldn't
be a minor change.

-d

On 11/16/2007 02:06 PM, David Gingold wrote:
>
> On Nov 16, 2007, at 2:42 PM, Jeff Squyres wrote:
>
>> 1. const: Sure, this seems like a good idea.  But it *is* an API
>> change, and I am in agreement with Bill Gropp that there should be no
>> API changes for MPI 2.1 (except for bug fixes).  Even if the API
>> changes supposedly won't matter (because someone will find a case
>> where it does matter).  More specifically: this is a slippery slope
>> for 2.1.  Making one "minor" change will lead to more minor changes
>> which will lead to ...
>
> If an implementation declares in its mpi.h:
>
>     int MPI_Send(const void *, int, MPI_Datatype, int, int, MPI_Comm);
>
> does this violate the existing standard?
>
> I don't see how this would break code that calls MPI_Send().  C
> libraries made a similar transition with the advent of ANSI C; I believe
> the const semantics are defined in a way that lets one do just this.
>
> The const declaration allows an important optimization when compiling
> the calling functions.  But if an implementation is allowed to do this,
> then perhaps there is no need to change to the standard.
>
> -dg
>