[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [mpi-21] Proposal EH2: add const keyword to the C bindings



Hi,

With this interface to the op function

       typedef void (MPI_User_function) ( void * a,
       void * b, int * len, MPI_Datatype * );

one could in principle use one user function definition for both C and
Fortran:

"Rationale. 

"The len argument allows MPI_REDUCE to avoid calling the function for
each element in the input buffer. Rather, the system can choose to apply
the function to chunks of input. In C, it is passed in as a reference
for reasons of compatibility with Fortran."

In fact, I remember one implementation where access to vectorized local
reduction intrinsics was only available in Fortran. That architecture
did not like deep layered stacks either.

Best regards.

Alexander

--
Dr Alexander Supalov
Intel GmbH
Hermuelheimer Strasse 8a
50321 Bruehl, Germany
Phone:          +49 2232 209034
Mobile:          +49 173 511 8735
Fax:              +49 2232 209029
 

-----Original Message-----
From: owner-mpi-21@xxxxxxxxxxxxx [mailto:owner-mpi-21@xxxxxxxxxxxxx] On
Behalf Of Dries Kimpe
Sent: Saturday, January 12, 2008 8:50 AM
To: mpi-21@xxxxxxxxxxxxx
Subject: Re: [mpi-21] Proposal EH2: add const keyword to the C bindings

A similar problem (and maybe more frequent) will be with the MPI
callback
functions (e.g. MPI_Op)

If we really want to implement const in all places where it makes sense,
-- for reasons of consistency and to help users avoid incorrect code --
we will break a lot of code:

For example: (MPI_Op_create)

  The calling list for the user function type is
       typedef void (MPI_User_function) ( void * a,
       void * b, int * len, MPI_Datatype * );

Since a should only be read, to be consistent, void * a should actually
be
const void * a; 

Making this modification would surely help catch bugs.

Also -- not related to the const issue --  it is rather strange that len
is passed by a pointer, since 'len' isn't meant to be modified?
Applying
the rule would yield 'const int * len', which is a rather strange (and
inefficient) way  to pass an integer. 

The attribute copy function is immune:
there the original attribute is passed by value (casted
to void *), and hence doesn't need an added const; 
(Well one could argue that it does need a const, but it will be casted
to
something else anyway)

   Dries

---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.