R: Re: [MPICH] MPI_Probe, MPI_Iprobe MPI_Bcast

[Thomas Moschny]

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."

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. 

And because of the reasons I mentioned in my other post, this single process 
can't find out whether it is obliged to call MPI_Bast by calling MPI_Probe.

- Thomas