MPI_Irecv(3)

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

πŸ’… NAME πŸ’…

okay bestie, gather round β€” this is MPI_Irecv from the MPI manual (section 3, yes ma'am), and it begins a nonblocking receive. that's the whole vibe. you're not waiting for the message like some kind of peasant, you're starting the receive and getting a cute little handle back so you can go do literally anything else. main character energy fr fr. πŸ¦‹


πŸ“œ SYNOPSIS πŸ“œ

int MPI_Irecv(void *buf, int count, MPI_Datatype datatype, int source, int tag,
MPI_Comm comm, MPI_Request *request)

int MPI_Irecv_c(void *buf, MPI_Count count, MPI_Datatype datatype, int source,
int tag, MPI_Comm comm, MPI_Request *request)

two flavors, both iconic: the regular one and the _c one that takes an MPI_Count instead of an int for count. pick your fighter. πŸ’–


✨ INPUT PARAMETERS ✨

these are the things you hand over. the lore. the tea. πŸŽ€

  • count β€” how many elements are chillin' in your receive buffer, as a non-negative integer. no negative counts bestie, we don't do that here.
  • datatype β€” the datatype of each element in that receive buffer (a handle).
  • source β€” the rank of whoever's sending to you, or MPI_ANY_SOURCE if you're in your "I'll take whoever shows up" era. (integer)
  • tag β€” the message tag, or MPI_ANY_TAG if you're not being picky. (integer)
  • comm β€” the communicator (handle). your lil friend group.

🌸 OUTPUT PARAMETERS 🌸

stuff you get back, no cap:

  • buf β€” the initial address of your receive buffer (a choice).
  • request β€” the communication request (handle). hold onto this, you'll need it later for things like MPI_Wait and MPI_Test. it's literally the receipt. 🧾

🧡 THREAD AND INTERRUPT SAFETY 🧡

okay so good news first: this routine is thread-safe. that means multiple threads can safely use it without you having to build your own thread locks or anything. queen shit. no user-provided locks required. periodt. πŸ‘‘

but β€” and there's always a but β€” it is not interrupt safe. the reason, typically, is that it uses memory allocation routines like malloc or other non-MPICH runtime routines, and those themselves are not interrupt-safe. so like, know that going in. πŸ’€


πŸŽ€ NOTES FOR FORTRAN πŸŽ€

for my Fortran girlies:

  • all MPI routines in Fortran (except for MPI_WTIME and MPI_WTICK) get an extra argument called ierr tacked onto the end of the argument list. ierr is an integer and it means the exact same thing as the return value of the routine in C.
  • in Fortran, MPI routines are subroutines, and you invoke them with the call statement. yes, like that.
  • also, literally all MPI objects (e.g., MPI_Datatype, MPI_Comm) are of type INTEGER in Fortran. that's just how it is.

😭 ERRORS 😭

okay so every single MPI routine (except MPI_Wtime and MPI_Wtick) returns an error value β€” in C it's the value of the function, and in Fortran it's the last argument. before that value comes back to you, the current MPI error handler gets called. and by default? that error handler aborts the entire MPI job. dramatic, I know.

you can swap the error handler out with:

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

there's also the MPI-1 routine MPI_Errhandler_set, which you may use, but heads up: its use is deprecated. we don't stan it anymore.

if you want error values to actually be returned instead of nuking your job, use the predefined error handler MPI_ERRORS_RETURN. 🫢

one more important thing: MPI does not guarantee that an MPI program can continue past an error. however, MPI implementations will attempt to continue whenever possible. so like, maybe. fingers crossed. 🀞

here's the error roster:

  • MPI_SUCCESS β€” no error! the MPI routine completed successfully. we love a clean run. ✨
  • MPI_ERR_ARG β€” invalid argument. some argument is invalid and isn't identified by a specific error class (e.g., MPI_ERR_RANK).
  • MPI_ERR_BUFFER β€” invalid buffer pointer. usually that's a null buffer in a spot where null is just not valid.
  • MPI_ERR_COMM β€” invalid communicator. a super common oopsie is using a null communicator in a call (which isn't 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 don't panic.
  • MPI_ERR_RANK β€” invalid source or destination rank. ranks must be between zero and the size of the communicator minus one; 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 attribute MPI_TAG_UB.
  • MPI_ERR_TYPE β€” invalid datatype argument. additionally, this error can happen if an uncommitted MPI_Datatype (see MPI_Type_commit) gets used in a communication call.
  • MPI_ERR_OTHER β€” other error; use MPI_Error_string to get more info about this error code.
pro tip from me to you: if you see MPI_ERR_OTHER, go ask MPI_Error_string what's going on. it's giving "just talk to me". πŸ™ˆ

and that's the whole page bestie, you ate that. this was the MPI manual, MPI_Irecv(3), dated 4/10/2026 β€” go start a nonblocking receive and slay. πŸ’…βœ¨πŸŽ€

πŸ“¦ where this page comes from