R: Re: [MPICH] MPI_Probe, MPI_Iprobe MPI_Bcast

[Ashley Pittman]

On Mon, 2006-09-18 at 15:54 +0200, Thomas Moschny wrote:
> On Monday 18 September 2006 15:33, Ashley Pittman wrote:
> > 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.
> 
> You are right, formally. The standard says, that "Collective routine calls can 
> (but are not required to) return as soon as their participation in the 
> collective communication is complete." 
> 
> However, especially wrt the original question starting this thread, 
> the 'advice to users' given a bit later in the standard is of importance to:
> 
> "[...] On the other hand, a correct, portable program must allow for the fact 
> that a collective call /may/ be synchronizing. Though one cannot rely on any 
> synchronization side-effect, one must program so as to allow it."

Yes, I was thinking of it from the other side of the coin, I once saw a
benchmark for MPI_Bcast() that was getting near infinite bandwidth as
the time was only measured on the root, relying on the behaviour either
way is a bad thing.

> That's what I had in mind here. And for sure it is always an error if one of 
> the members of a process group doesn't call MPI_Bcast while all others do. 

Indeed, this is quite an important thing to understand if just starting
off with MPI.

Ashley,