[mpiwg-tools] Ticket 358

[Bronis R. de Supinski]

I do not see why your proposal is necessary or apprpriate.
If I want to redefine MPI_Send to be MPI_Recv (or more
likely to send to /dev/null) I can do it. THe MPI standard
cannot prohibit it and it has no impact on the conformance
of the implementation that I am using.



On Tue, 3 Feb 2015, Marc-Andre Hermanns 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
>
>