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

[Jeff Hammond]

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.

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

Jeff

On Sun, Dec 6, 2015 at 10:04 PM, Jed Brown <jed at jedbrown.org> wrote:

> In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r ==
> MPI_REQUEST_NULL.  This is also the case for other communicators of size
> 1.  Previous versions of MPICH and also all versions of Open MPI return
> a valid request not equal to MPI_REQUEST_NULL.  This bit me because it
> was natural to compare to MPI_REQUEST_NULL in a conditional for an
> Ibarrier/Issend/Iprobe algorithm.  It can be worked around with a
> slightly more complicate conditional, but is this change intentional?
>
>   The call returns a request handle, which must be passed to a
>   completion call.
>   -- MPI-3 §5.12
>
> This does not say "unless the communicator has size 1".
>
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
>



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20151207/adeae46d/attachment.html>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss