3

I have a program where there is a master/slave setup, and I have some functions implemented for the master which sends different kinds of data to the slaves. Some functions send to individual slaves, but some broadcast information to all the slaves via MPI_Bcast.

I want to have only one receive function in the slaves, so I want to know if I can probe for a message and know if it was broadcasted or sent as a normal blocking message, since there are different method to receive what was broadcasted and what was sent normally.

Gumeo
  • 891
  • 1
  • 13
  • 26

1 Answers1

6

No, you can't decide whether to call Bcast or Recv on the basis of a probe call.

A MPI_Bcast call is a collective operation -- all MPI tasks must participate. As a result, these are not like point to point communication; they make use of the fact that all processes are involved to make higher-order optimizations.

Because the collective operations imply so much synchronization, it just doesn't make sense to allow other tasks to check to see whether they should start participating in a collective; it's something which has to be built into the logic of a program.

  • The root process' role in a broadcast is not like a Send; it can't, in general, just call MPI_Bcast and then proceed. The implementation will almost certainly block until some other number of processes have participated in the broadcast; and

  • The other process' role in a broadcast is not like receiving a message; in general it will be both receiving and sending information. So participating in a broadcast is different from making a simple Recv call.

So Probe won't work; the documentation for MPI_Probe is fairly clear that it returns information about what would happen upon the next MPI_Recv, and Recv is a different operation than Bcast.

You may be able to get some of what you want in MPI 3.0, which is being finalized now, which allows for nonblocking collectives -- eg, MPI_Ibcast. In that case you could start the Broadcast and call MPI_Test to check on the status of the request. However, even here, everyone would need to call the MPI_Ibcast first; this just allows easier interleaving of collective and point-to-point communication.

Jonathan Dursi
  • 50,107
  • 9
  • 127
  • 158
  • Thanks for the response! I think I can fix this by sending a blocking message to all the slaves before the broadcast with a tag which tells the receive function to "prepare" for a broadcast. I'm migrating a project from PVM to MPI and in PVM they have a function called pvm_mcast, which behaves similar to MPI_Bcast, but you can receive it with a nonblocking receive, was just wandering if there was something similar in MPI. I'm gonna read a bit on the nonblocking collectives. – Gumeo Jun 13 '12 at 13:38
  • 1
    `pvm_mcast` is different from `MPI_Bcast`. It is a multicast operation, not a broadcast one, and its semantics are similar to what you get if you issue multiple `MPI_Send` operations. It allows you to send data to an arbitrary subset of processes while `MPI_Bcast` sends data to _all_ processes and that allows for some higher level optimisations. If the original code did not use `pvm_mcast` to perform full broadcast it would be better to just stick with a bunch of `MPI_Isend` followed by `MPI_Waitall`. Then you'd be able to probe. – Hristo Iliev Jun 13 '12 at 13:59
  • Thank you, I think I have now fully grasped the idea of pvm_mcast and it's functionality compared to MPI_Bcast. – Gumeo Jun 13 '12 at 14:13