[mpiwg-p2p] how to classify ticket 471 ("MPI_START(ALL) restrictions")?

Jeff Hammond jeff.science at gmail.com
Mon Jan 19 11:56:12 CST 2015


I missed "The associated request should be inactive." in the MPI_START
semantics, which resolves a lot of my issues in favor of what Dan said
on the telecon today.

Jeff

On Fri, Jan 16, 2015 at 10:54 AM, Jeff Hammond <jeff.science at gmail.com> wrote:
> Thanks for your comments, Dan.
>
>> MPI 3.0 p78 lines 18-25 (section 3.9) forces the correct sequence and
>> explicitly calls out the case of multiple concurrent threads.
>
> My reading of the text of lines 14-18 is to constrain the use of
> MPI_REQUEST_FREE and nothing else.  It so happens that line 21
> _implies_ additional restrictions, but these are not stated.  And
> given that line 21 is preceded by "If this rule [pertaining to
> MPI_REQUEST_FREE] is followed..." it is not unreasonable to interpret
> line 21 as a non-normative illustration of the rule described in
> 14-18.
>
> Only if one reads line 21 as both normative and itself a constraint on
> its own (i.e. ignoring its relationship to lines 14-18), does one
> conclude that starting a request twice without completing it first is
> prohibited.
>
>> Also, a MPI_STARTALL call "has the same effect as" lots of MPI_START calls
>> "in some arbitrary order" p78 lines 5-7 plus "the request should be
>> inactive... becomes active once the call is made" p77 lines 28-29 so
>> specifying a request more than once in the vector to MPI_STARTALL is pretty
>> much guaranteed to break the correct sequence and the chronologically second
>> implied MPI_START will be supplied with an active request, which is defined
>> to be bad.
>
> I agree that the constraint on STARTALL follows immediately once it is
> established for START.
>
>> I think that section 3.9 is fine and deals with all your points of possible
>> ambiguity. Section 12 then incorrectly tries to un-write some of those rules
>> by absent-mindedly neglecting the existence of persistent requests. Changing
>> the text you quote (section 12.4.3), in particular "In MPI, a request can
>> only be completed once" - *buzzz*, fail - is, IMHO, errata because the
>> Standard is semantically (rather than just syntactically) wrong and needs to
>> be corrected. Determining ticket-0 on this is a matter for the External
>> Interfaces chapter committee. An errata could be brought by this WG because
>> it is point-to-point functionality that is causing the conflict or by the
>> Hybrid WG because it is all the fault of those pesky threads again.
>
> I recall that am one of the very few members of that chapter
> committee.  I will propose changes for the external interfaces chapter
> that I will then argue in the corresponding chapter committee context
> are ticket-0 :-)
>
> Best,
>
> Jeff
>
>> On 16/01/2015 17:00, Jeff Hammond wrote:
>>>
>>> I created https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/471 last
>>> night.  Jim and Sayantan the overall concept is noncontroversial.
>>>
>>> Is this ticket-0, an errata, or something that has to be read for MPI-4?
>>>
>>> Thanks,
>>>
>>> Jeff
>>>
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>> _______________________________________________
>> mpiwg-p2p mailing list
>> mpiwg-p2p at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p
>
>
>
> --
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/



More information about the mpiwg-p2p mailing list