MPI_Recv(3)

πŸ“¦
version 5.0.1 Β· 5 versions
, in nixos 26.05, ubuntu stonking

πŸ’Œ NAME

MPI_Recv β€” the blocking receive for a message, aka the moment your program sits there like "bestie I am NOT moving until that message shows up" πŸ’…

This one lives in section 3 of the MPI manual (that's the (3) on the tin, iykyk).


✨ SYNOPSIS ✨

int MPI_Recv(void *buf, int count, MPI_Datatype datatype, int source, int tag,
MPI_Comm comm, MPI_Status *status)

int MPI_Recv_c(void *buf, MPI_Count count, MPI_Datatype datatype, int source,
int tag, MPI_Comm comm, MPI_Status *status)

Yes there are two of them and yes the second one is just the first one with a glow-up on count. We love a range. πŸ¦‹


πŸ“₯ INPUT PARAMETERS πŸ“₯

Things you gotta hand over when you call her:

  • count β€” how many elements fit in your receive buffer. Gotta be a non-negative integer, no skips. (It's the max length, more on that down in NOTES πŸ‘€)
  • datatype β€” the datatype of each element in the receive buffer (it's a handle).
  • source β€” the rank of whoever's sending, or MPI_ANY_SOURCE (an integer).
  • tag β€” the message tag, or MPI_ANY_TAG (an integer).
  • comm β€” the communicator (a handle).

πŸ“€ OUTPUT PARAMETERS πŸ“€

Things she hands back to you:

  • buf β€” the initial address of the receive buffer (a choice).
  • status β€” the status object (a Status).

πŸ“ NOTES πŸ“

Okay so here's the tea: that count argument is the maximum length of a message. It is not a promise about how much actually shows up. If you wanna know the actual length of the message you got? That's a whole separate quest β€” go ask MPI_Get_count. πŸ’–


🧡 THREAD AND INTERRUPT SAFETY 🧡

This routine is thread-safe. Translation: multiple threads can use it at the same time and nobody needs to bring their own thread locks. It just works. Slay.

BUT. She is not interrupt safe. No interrupt-safe energy here, periodt. Usually this is because of memory allocation routines like malloc, or other non-MPICH runtime routines, that are themselves not interrupt-safe. So like… don't interrupt her mid-glow-up, fr fr. 😭


🏰 NOTES FOR FORTRAN 🏰

Every MPI routine in Fortran β€” except for MPI_WTIME and MPI_WTICK, those two are the rebels β€” has one extra argument tacked onto the end of the argument list: ierr. It's an integer, and it means the exact same thing as the return value of the routine does in C.

Also, in Fortran, MPI routines are subroutines, and you invoke them with the call statement. Iconic and traditional.

And every MPI object (like MPI_Datatype, MPI_Comm) is of type INTEGER in Fortran. Every single one. That's just the lore. πŸ‘‘


πŸ’€ ERRORS πŸ’€

Every MPI routine (except MPI_Wtime and MPI_Wtick) returns an error value β€” C routines as the value of the function, Fortran routines in that last argument we just talked about.

Before that value comes back to you, the current MPI error handler gets called. And by default? That error handler aborts the MPI job. Not a vibe check, an actual abort. 😳

You can change the error handler with:

  • MPI_Comm_set_errhandler β€” for communicators
  • MPI_File_set_errhandler β€” for files
  • MPI_Win_set_errhandler β€” for RMA windows

The MPI-1 routine MPI_Errhandler_set may be used too, but heads up: its use is deprecated. Don't be the one still using it in 2026 bestie please.

There's also the predefined error handler MPI_ERRORS_RETURN, which you can use to make error values actually get returned to you instead of everything going up in flames.

⚠️ And note β€” MPI does not guarantee that an MPI program can continue past an error. However, MPI implementations will attempt to continue whenever possible. So like, it might be fine. It might not. Roll the dice. 🎲

Here's the full squad of error codes:

  • MPI_SUCCESS β€” No error; MPI routine completed successfully. We love a clean run. ✨
  • MPI_ERR_ARG β€” Invalid argument. Some argument is invalid and is not identified by a specific error class (e.g., MPI_ERR_RANK).
  • MPI_ERR_BUFFER β€” Invalid buffer pointer. Usually a null buffer where one is not valid. Sir. Please. A null buffer? Here?
  • MPI_ERR_COMM β€” Invalid communicator. A super common oopsie is using a null communicator in a call (it's not even allowed in MPI_Comm_rank).
  • MPI_ERR_COUNT β€” Invalid count argument. Count arguments must be non-negative; a count of zero is often valid though, so zero isn't always the problem. πŸ“
  • MPI_ERR_RANK β€” Invalid source or destination rank. Ranks must be between zero and the size of the communicator minus one. But ranks in a receive (MPI_Recv, MPI_Irecv, MPI_Sendrecv, etc.) may also be MPI_ANY_SOURCE.
  • MPI_ERR_TAG β€” Invalid tag argument. Tags must be non-negative; tags in a receive (MPI_Recv, MPI_Irecv, MPI_Sendrecv, etc.) may also be MPI_ANY_TAG. The largest tag value is available through the the attribute MPI_TAG_UB. (yes, "the the" β€” she's a little quirky, we keep her as she is 🫢)
  • MPI_ERR_TYPE β€” Invalid datatype argument. Also, this one can pop up if an uncommitted MPI_Datatype (see MPI_Type_commit) is used in a communication call. Commit before you transmit, bestie.
  • MPI_ERR_OTHER β€” Other error; use MPI_Error_string to get more information about this error code. The catch-all bin. πŸ™ˆ

and that's the whole page, no cap πŸ’–

This was MPI documentation, dated 4/10/2026, from the MPI source β€” MPI_Recv(3), section 3, out. Go receive something iconic. πŸŒˆπŸŽ€πŸ¦‹

πŸ“¦ where this page comes from