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

Jeff Hammond jeff.science at gmail.com
Fri Jan 16 12:54:33 CST 2015


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/



More information about the mpiwg-p2p mailing list