[mpiwg-tools] Ticket 358

[Jeff Squyres (jsquyres)]

I think MPI-3.0 14.2.2 and 14.2.3 cover the correctness of the situation (i.e., if you provide MPI_Foo, then it must conform to the defined semantics of MPI_Foo).

That being said, you have a point about the declared vs. defined language.


> On Feb 4, 2015, at 2:28 AM, Marc-Andre Hermanns <m.a.hermanns at grs-sim.de> wrote:
> 
> Hi Martin,
> 
> I see Rolf's point, although I am am unsure whether the initial wording
> of the change in 453 is correct.
> 
> If you see it from the C perspective, declaration and definition are two
> separate things. However, the standard only talks about declaration of
> functions in the MPI_ namespace. That, IMHO, should never be allowed.
> What should be allowed is to "define already declared functions in the
> MPI_ namespace."
> 
> I am unsure whether Fortran also has this distinction. C/C++ certainly
> has. If we now allow the _declaration_ of calls in the MPI_ namespace,
> then it would allow me to define MPI_Whatever(), which I think should
> still not be allowed.
> 
> Off the cuff, I would try to find a wording that goes along the lines of:
> 
> "... any redefined function in the MPI_ namespace must guarantee the
> semantics defined in the standard, but is allowed to have additional
> side effects".
> 
> This is too rough cut, still. Yet, what I want to express is that any
> re-definition should not change the expected behavior of the call.
> 
> Examples:
> - A non-blocking call should not suddenly block.
> - A blocking call must still ensure that the user buffer can safely be
> re-used after the call returns.
> - A broadcast should still be a call where the source of the data is the
> root and after completion all other processes have a copy of the root's
> buffer. (and not suddenly implement a reduce).
> 
> This would still cover MPIEcho, because the additional MPI_Sends on the
> slave processes can be regarded as side effects, right?. The application
> still just sees the expected behavior of one message being sent from
> process to process.
> 
> Cheers,
> Marc-Andre
> 
> On 04.02.15 06:17, Schulz Martin wrote:
>> I am still not convinced we need this, but if we find the right language I
>> am not opposed to it. Not sure, how we can write this the right way. This
>> gets fuzzy very easily. Do you have a suggestion?
>> 
>> Martin
>> 
>> ________________________________________________________________________
>> Martin Schulz, schulzm at llnl.gov, http://scalability.llnl.gov/
>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>> 
>> 
>> 
>> 
>> 
>> On 2/3/15, 8:37 AM, "Marc-Andre Hermanns" <m.a.hermanns at grs-sim.de> wrote:
>> 
>>> Dear all,
>>> 
>>> I just got a chance to talk to Rolf on this ticket:
>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/358
>>> 
>>> The reason for this ticket was that in ticket 453
>>> (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/453), which passed
>>> as 3.0 errata, it is now explicitly allowed to declare functions in the
>>> MPI_ namespace, as long as the user wants to make use of the profiling
>>> interface.
>>> 
>>> The question now is, whether we should have a clarifying sentence in the
>>> profiling chapter to tell users of the interface not to tamper with the
>>> existing semantics of specific calls.
>>> 
>>> Rolf understood that the current wording in the ticket may be too
>>> ristrictive, as it remains unclear what 'fully conforms' still allows.
>>> His suggestion was maybe a less restrictive wording, where tools like
>>> MPIEcho are still allowed.
>>> 
>>> Cheers,
>>> Marc-Andre
>>> -- 
>>> Marc-Andre Hermanns
>>> Jülich Aachen Research Alliance,
>>> High Performance Computing (JARA-HPC)
>>> German Research School for Simulation Sciences GmbH
>>> 
>>> Schinkelstrasse 2
>>> 52062 Aachen
>>> Germany
>>> 
>>> Phone: +49 241 80 99753
>>> Fax: +49 241 80 6 99753
>>> www.grs-sim.de/parallel
>>> email: m.a.hermanns at grs-sim.de
>>> 
>> 
>> 
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>> 
> 
> -- 
> Marc-Andre Hermanns
> Jülich Aachen Research Alliance,
> High Performance Computing (JARA-HPC)
> German Research School for Simulation Sciences GmbH
> 
> Schinkelstrasse 2
> 52062 Aachen
> Germany
> 
> Phone: +49 241 80 99753
> Fax: +49 241 80 6 99753
> www.grs-sim.de/parallel
> email: m.a.hermanns at grs-sim.de
> 
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/