[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MPI_FINALIZE
MPI_Bcast is collective but I would be surprised if a implementation chose
to make the tasks close to root block while waiting for the tasks farther
out to process a correct call. When MPI states that only MPI_Barrier
__promises__ a synchronization, the reason is that in many collectives
making all calls wait to confirm all others had occured correctly would
reduce performance and add little value.
MPI_Bcast on an intercommunicator is collective but involves calls by tasks
which have no participation in the operation at all. These tasks pass
MPI_PROC_NULL as root and an MPI implementation that made these calls into
local no-ops could be valid. A program that __presumed__ they were local
no-ops and could be omitted would be invalid.
Dick Treumann RS/6000 SP Development
IBM Poughkeepsie Unix Development Lab
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
"Andrew
Lumsdaine" To: <mpi-21@mpi-forum.org>, "Jeff Squyres"
<lums@lsc.nd.edu <jsquyres@lam-mpi.org>
> cc: <mpi-21@mpi-forum.org>
Sent by: Subject: Re: MPI_FINALIZE
owner-mpi-21@mpi
-forum.org
05/10/2001 02:07
PM
Please respond
to mpi-21
Hum. If I understand the idea of "collective" properly, then I don't see
how
this can be accomplished without something like a barrier occurring. Does
not the requirement that all the processes have to call the MPI routine
also
imply that it is an error if they do not all do so? Does not that also
imply that each process needs to wait until all processes have made the
collective call in order to know whether the collective call has been
properly made or not?
Otherwise, I don't think MPI_Finalize would be truly collective. I.e., if
one can call it and receive indication of success regardless of whether
anyone else ever calls it or not, then it seems like a local procedure.