R: Re: [MPICH] MPI_Probe, MPI_Iprobe MPI_Bcast

[Ashley Pittman]

On Fri, 2006-09-15 at 18:01 +0100, Eng. A.A. Isola wrote:
> Ok for the answer, but there's anything that don't work...
> 
> 
> For ex.
> "No, because MPI_Bcast is a collective operation. All members of the
>  
> communicator used there must call MPI_Bcast simultaneously, behaves 
> like a barrier. So if one of the members doesn't call MPI_Bcast, you'll 
> have a deadlock."
> 
> Sorry but the MPI_Barrier is a collective BLOCKING 
> routine, then if for ex. there're 3 processes, and 1 of them for any 
> reasons is too much slow and don't call the MPI_Bcast, the others 2 
> processes will wait it. Isn't mandatory that all the processes call the 
> MPI_Bcast "simultaneously", because the fater processes will wait the 
> slower (like the MPI_Barrier as you say).

I don't believe this is technically true if you read the spec carefully.
Obviously MPI_Barrier() performs a barrier and any process will block
until all other processes have made the same call, it is after all the
purpose of the function.

MPI_Bcast() on the other hand *doesn't* make any statement about
performing a barrier, all it states is that you receive data from the
root.  There are some implementations that spring to mind (mpich1
springs to mind) where the root sends the data onto the network and then
returns without waiting for the data to arrive.

MPI_Barrier is the only collective that explicitly has to block until
all processes have called the function according to the spec although
MPI_AllReduce(), MPI_AllGather() and MPI_Alltoall() also need to perform
a barrier as you need the data from each process before any process can
return.

Ashley,