[Mpi-forum] Progress Question

[Jim Dinan]

Hi Rajeev,

Yes, that's the question and my initial answer was the same as yours.
However, we then started talking about the implementation of the barrier,
which led to the second example. For example, consider a situation where
there is an error in transmission and the implementation needs to enter the
progress engine to retry a send operation in software.

 ~Jim.

On Sat, Oct 10, 2020 at 5:10 PM Thakur, Rajeev <thakur at anl.gov> wrote:

> Jim,
>
>       I don’t fully understand your question. Is it “If all processes
> reach MPI_Barrier, are they guaranteed to exit the barrier without the need
> for any other MPI function to be called on any process?” I would say yes.
>
>
>
> Rajeev
>
>
>
>
>
> *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>
> *Reply-To: *Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>
> *Date: *Saturday, October 10, 2020 at 12:31 PM
> *To: *Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>
> *Cc: *Jim Dinan <james.dinan at gmail.com>
> *Subject: *[Mpi-forum] Progress Question
>
>
>
> Hi All,
>
>
>
> A colleague recently asked a question that I wasn't able to answer
> definitively. Is the following code guaranteed to make progress?
>
>
>
> MPI_Barrier();
>
> if rank == 1
>
>   create_file("test")
>
> if rank == 0
>
>    while not_exists("test")
>
>        sleep(1);
>
>
>
> 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[0])
>
> irecv(..., other_rank, &req[1])
>
> waitall(2, req)
>
> if rank == 1
>
>   create_file("test")
>
> if rank == 0
>
>    while not_exists("test")
>
>        sleep(1);
>
>
>
> I think it would clearly not guarantee progress since the send data can be
> buffered. Is the same true for barrier?
>
>
>
> Cheers,
>
>  ~Jim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20201011/f0111a03/attachment.html>