[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpi-21] MPI Forum suggestions 11/14
On 11/16/07, Erez Haba <erezh@xxxxxxxxxxxxx> wrote:
> 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?
AFAIK, there is. Please, see:
http://www.mpi-forum.org/docs/mpi-11-html/node40.html
>
>
> -----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
> >
>
>
--
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594