[Mpi-forum] [EXT]: Progress Question
Tony-Skjellum at utc.edu
Sat Oct 10 13:17:00 CDT 2020
Jim, OK, my attempt at answering below.
See if you agree with my annotations.
Anthony Skjellum, PhD
Professor of Computer Science and Chair of Excellence
University of Tennessee at Chattanooga (UTC)
tony-skjellum at utc.edu [or skjellum at gmail.com]
From: mpi-forum <mpi-forum-bounces at lists.mpi-forum.org> on behalf of Jim Dinan via mpi-forum <mpi-forum at lists.mpi-forum.org>
Sent: Saturday, October 10, 2020 1:31 PM
To: Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>
Cc: Jim Dinan <james.dinan at gmail.com>
Subject: [EXT]: [Mpi-forum] Progress Question
A colleague recently asked a question that I wasn't able to answer definitively. Is the following code guaranteed to make progress?
-- everything is uncertain to within one message, if layered on pt2pt;
--- let's assume a power of 2, and recursive doubling (RD).
--- At each stage, it posts an irecv and isend to its corresponding element in RD
--- All stages must complete to get to the last stage.
--- At the last stage, it appears like your example below for N/2 independent process pairs, which appears always to complete.
Oif rank == 1
if rank == 0
That is, can rank 1 require rank 0 to make MPI calls after its return from the barrier, in order for rank 1 to complete the barrier? If the code were written as follows:
isend(..., other_rank, &req)
irecv(..., other_rank, &req)
--- Assume both isends buffer on the send-side and return immediately--valid.
--- Both irecvs are posted, but unmatched as yet. Nothing has transferred on network.
--- Waitall would mark the isends done at once, and work to complete the irecvs; in
that process, each would have to progress the isends across the network. On this comm
and all comms, incidentally.
--- When waitall returns, the data has transferred to the receiver, otherwise the irecvs
if rank == 1
if rank == 0
I think it would clearly not guarantee progress since the send data can be buffered. Is the same true for barrier?
This message is not from a UTC.EDU address. Caution should be used in clicking links and downloading attachments from unknown senders or unexpected email.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mpi-forum