[mpich-discuss] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2

[Jed Brown]

Jeff Hammond <jeff.science at gmail.com> writes:

> Completed requests are set to MPI_REQUEST_NULL.  Since MPI_Ibarrier (and
> MPI_Barrier) is a no-op for a communicator of size 1, it is trivially
> complete and it would seem that MPICH is optimizing away the unnecessary
> request object here.

Of course it's an "optimization", but I think it may be meaningless and
it's not clear to me that it's allowed by the standard.

Note the explicitness in malloc(3):

  If size is 0, then malloc() returns either NULL, or a unique pointer
  value that can later be successfully passed to free().

Specifically, the MPI standard doesn't say that it "returns a request
that must be completed in a separate completion call, or
MPI_REQUEST_NULL indicating that the operation already completed".

> Why don't you use MPI_Test instead of direct comparison?

It's a state conditional to distinguish between two phases of the
algorithm.  I can use an extra flag, but the existing version
initializes req=MPI_REQUEST_NULL and expects that starting an Ibarrier
will make req equal to something else.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20151207/eb93f477/attachment.sig>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss