This is an old revision of the document!


This Wiki page is outdated, please go to:

Using the ''status'' parameter in ''Recv''

In order to access the status information from the Recv method, an instance of Status-class has to be created and passed to the status parameter of Recv:

info = MPI.Status()

The information about the received message is returned by calls to various methods of the class Status instance info:

info.Get_count()             returns message size in Bytes
info.Get_elements(datatype)  returns number of elements 
                             of type datatype 
info.Get_source()            returns message source
info.Get_tag()               returns message tag

An example for retrieving the status information is (from now on the code lines for importing modules and defining comm, size and rank will be not displayed)

data = rank*numpy.ones(5,dtype = numpy.float64)

if rank == 0:
if rank == 1:
   info = MPI.Status()
   source = info.Get_source()
   tag = info.Get_tag()
   count = info.Get_elements(MPI.DOUBLE)
   size = info.Get_count()
   print 'on',rank, 'source, tag, count, size is',source, tag, count, size

which running in two tasks produces the output

on 1 source, tag, count, size is 0 1 3 24

A Recv operation will fail, if the size of the buffer passed in the Recv call is smaller than the message size to be received. A possible failure of this kind can be avoided by inquiring the message status with the Probe method before executing the actual Recv operation with a buffer of appropriate size. This is demonstrated in the following example:

if rank == 0:
   data = rank*numpy.ones(5,dtype = numpy.float64)
if rank == 1:
   info = MPI.Status()
   count = info.Get_elements(MPI.DOUBLE)
   data = numpy.empty(count,dtype = numpy.float64)
   print 'on',myid, 'data: ',data

Blocking and Nonblocking Communications

MPI offers two basic ways for communication, both of which can be used in mpi4py.

1. Blocking Communication, in which a call to a communication request returns, when the memory location, which contains the data to be communicated, can safely be used for subsequent instructions. For the Send operation this is the case, when all data have been copied from their local memory location to the receive buffer of the receiving task. The Send operation therefore in general is nonlocal, depending on the activities of the receiving tasks. The Recv call will return, when a message with the given attributes has been copied to its memory location. Also Recv is nonlocal, because its completion depends on the previous posting of a send operation in a different task. Blocking communication may lead to a deadlock, if a communication call of one task is not matched with a corresponding call of another task.

The mpi4py class Comm supplies the functions send and recv for generic python data objects and Send and Recv for buffer like data objects, as described above.

2. Nonblocking Communication, in which the communication call returns immediately, allowing to perform other computations not depending on the data of the actual communication. This overlapping of communication and computation can be profitable, if the underlying communication system has its own hardware support. Nonblocking communication on both ends has two stages: Posting the communication call and and subsequently enquiring the status of the communication request in order to establish the completion of the communication.

In MPI the names for nonblocking communication calls are derived from the respective names for the blocking calls by prepending an “i” (for immediate). mpi4py provides the functions isend resp. Isend and irecv resp. Irecv for the nonblocking communication calls. These function calls return an instance of the mpi4py class Request. The methods Wait and Test and variants thereof of the Request instance can be used for enquiring the status of the communication.

The following example shows a nonblocking communication of a NumPy array, in which the two methods Wait and Test are used to controll the completion of the Irecv call.

a_size = 10
data = (1+rank)*numpy.arange(a_size,dtype=numpy.float64)
if rank == 0:
elif rank == 1:
    print 'on task',rank,'before recv:   data = ',data
    re = False
    while re == False :
    print 'test result',re
    print 'wait result',re
    print 'on task',rank,'after recv:    data = ',data

Modes of Communications

The blocking send operation can be implemented by directly streaming the message data from memory into the communcation system. In this case the send call will block until a corresponding receive call has been posted and copied the data stream into the memory of the receiving task. This is called the synchronous communication mode.

Alternatively, the implementation can copy the message data into a local buffer, before streaming it into the communication system. This buffered communication mode allows the send call to return immediatly after completion of the local copy operation, irrespective of the posting of a matching receive call.

A third possibility is an implementation, in which the send call can be started only, if a matching receive call already has been posted, such that the overhead for establishing the availability of the receiver may be avoided. In this ready communication mode the send operation will return with an error, if a matching receive call has not been not posted previously.

The standard send operation in MPI is a combination of buffered mode for short and synchronous mode for long messages. The border between the two modes is implementation dependend, portable programs using the standard send should not depend on properties of one of the modes.

MPI provides access to the other three modes in send routines, whose names are prepended by the letters “s”, “b”, and “r”, respectively. The buffer used in the buffered mode bsend call has to be explicitely attached to the MPI environment. The receive call is the same for all modes. The four modes are available also for the nonblocking communucation calls.

mpi4py provides in its Comm-class functions with upper case first letter for sending buffer like objects

Send, Ssend, Bsend, Rsend        blocking calls
Isend, Issend, Ibsend, Irsend    nonblocking calls

and with lower case first letter for sending generic python data objects

send, ssend, bsend               blocking calls
isend, issend, ibsend            nonblocking calls
no ready mode send for generic python data objects

Furthermore the mpi4py function Attach_buffer(memory) provides a buffer in the application's memory space for use in a buffered mode send operation. The size of the buffer must be large enough to receive the message data and additional information concerning the message (size, destination, identification).

The next example shows a buffered send and the syntax to attach the buffer. As you can see, the size of the buffer is slightly larger than the size of the data to be sent, because the message-data contain in addition to the data proper also information about their size, the destination and the identifier of the message.

a_sz = 1000
data = rank*numpy.arange(a_sz,
if rank == 0:
    buf = numpy.empty(a_sz+3,dtype =
elif rank == 1:
    print 'on task',rank,'before recv:   data = ',data[a_sz-1]
    print 'on task',rank,'after recv:    data = ',data[a_sz-1]

Avoiding deadlocks by using ''Sendrecv''

Exchanging data between neighbours in a ring of tasks can lead to a deadlock, as exemplified in the following program:

a_size = 10
ipr = (rank +1)%size
ipl = (rank -1)%size

print 'on task',rank,'data:',send_data[1],recv_data[1]

This program will never end, because every tasks posts a call to the synchroneous mode Ssend, which will not return before the matching receive call is posted, and will never proceed to post the receive call. Using instead the standard mode Send is not a good solution, because the program will complete or hang depending on the amount of exchanged data. MPI provides a special function combining the send and recv operation, which garantees an execution without deadlock. In the given example the calls to Ssend and Srecv should be replaced by the single call

comm.Sendrecv(send_data,dest=ipl, \

Collective Communications

Point to point communication is the basic tool for parallel computing within the messige passing programming model. More general communication patterns involving more than two tasks can be realised by combining several of these basic communication operations. For example synchronising all tasks in a communicator can be achieved by handshakes of one tasks with all other tasks and informing all tasks about the completion of all these handshakes. This is illustrated with the code for the function synchron.

def synchron():
   buf = None
   if rank == 0:
      for ip in range(1,size):
      for ip in range(1,size):
     buf = comm.recv(source=0)

This kind of synchronisation can be thought of as a barrier, which stops every task until all tasks have arrived. A barrier may be used for example to force the output of several tasks, which without intervention will follow one after the other in a runtime dependent order, into a prescribed seqence:

for ip in  range(0,size):
   if rank == ip:
      print 'rank',rank,'ready'

Communication involving all tasks of a communicator is called collective within the MPI standard. The MPI standard provides subroutines for barrier synchronisation and for a large number of other frequently used patterns of collective data manipulations.

These patterns can be classified according to the kind of data manipulation involved

  • Global Synchronisation, no data are involved
  • Global data communication, data are scattered ore gathered
  • Global data reduction, data of different tasks are reduced to new data

Global Synchronisation

The only global synchronisation operation in MPI is the barrier. The syntax for the barrier synchronisation function in the mpi4py Comm class equivalent to the synchron function above is


A task posting a call to Barrier() will halt until all other tasks of the communicator have posted the same call. Therefore in a correct mpi4py program the number of calls to Barrier() must be equal for all tasks.

Global Data Communication

Data communication between all tasks of a communicator can have two directions:

  • distributing data coming from one tasks to all tasks
  • collecting data coming from all tasks to one or all tasks

For distributing data mpi4py provides functions for

  • broadcasting: Bcast, bcast
  • scattering from one task: Scatter, Scatterv, scatter

For collecting data mpi4py provides functions for

  • gathering to one task: Gather, Gatherv, gather
  • gathering to all tasks: Allgather, Allgatherv, allgather

In addition, there are functions, which combine collection and distribution of data:

  • Alltoall, Alltoallv, Alltoallw, alltoall


The syntax of the broadcast method is

comm.Bcast(buf, int root=0)
buf = comm.bcast(obj=None, int root=0)

An example for broadcasting an NumPy array is

data = numpy.empty(5,dtype=numpy.float64)
if rank == 0:
    data = numpy.arange(5,dtype=numpy.float64)
print 'on task',rank,'after recv:    data = ',data

An example broadcasting a python data object is

rootdata = None
if rank == 0:
    rootdata = (1,'a','z',3.14)
data = comm.bcast(rootdata,root=0)
print 'on task',rank,'after bcast:    data = ',data

A difference between the two broadcast functions is, that in Bcast the data to be broadcasted stay in place in the root task, whereas in bcast, they are copied to the object returned by the call to bcast.


Whereas a broadcast operation distributes the same object from the root task to all other tasks, a scattering operation sends a different object from root to every task. The syntax of the methods for scattering is

comm.Scatter(sendbuf, recvbuf, int root=0)
comm.Scatterv(sendbuf, recvbuf, int root=0)
comm.scatter(sendobj=None, recvobj=None, int root=0)

In the upper case function Scatter the sendbuf and recvbuf arguments must be given in terms of a list (as in the point to point function Send):

buf = [data, data_size, data_type]

where data must be a buffer like object of size data_size and of type data_type. The size and type descriptions can be omitted, if they are implied by the buffer object, as in the case of a NumPy array. Equally sized sections of the data in sendbuf will be sent from root to the other tasks, the i-th section to task i, where they will be stored in recvbuf. The data_size in sendbuf therefore must be a multiple of size, where size is the number of tasks in the communicator. The data_size in recvbuf must be at least as large as the size of the data section received.

In the vector variant of this function, Scatterv, the size and the location of the sections of senddata to be distributed may be freely chosen. The sendbuf in this case must include a description of the layout of the sections in the form

sendfbuf = [data, counts, displacements, type]

where counts and displacements are integer tuples with as many elements as tasks are in the communicator. counts[i] designates the size of the i-th segment, displacements[i] the number of the element in data used as the first element of the i-th section.

The calls of Scatter and Scatterv are illustrated in the next example


a_size = 4
recvdata = numpy.empty(a_size,dtype=numpy.float64)
senddata = None
if rank == 0:
   senddata = numpy.arange(size*a_size,dtype=numpy.float64)
print 'on task',rank,'after Scatter:    data = ',recvdata

recvdata = numpy.empty(a_size,dtype=numpy.float64)
counts = None
dspls = None
if rank == 0:
   senddata = numpy.arange(100,dtype=numpy.float64)
print 'on task',rank,'after Scatterv:    data = ',recvdata

In the scatter function the sendobj to be scattered from the root task must be a sequence of exactly size objects, where size is the number of tasks in the communicator. Each element in this sequence can be a data object of any type, and the i-th object of the sequence will be sent from root to the i-th task and will be received in the i-th tasks as the value returned from scatter. This is shown in the following example program

rootdata = None
if rank == 0:
    rootdata = [1,2,3,(4,5)]
data = comm.scatter(rootdata,root=0)
print 'on task',rank,'after bcast:    data = ',data


The gather operations collects data from all tasks and delivers this collection to the root task or to all tasks. The syntax of the gathering methods is

comm.Gather(sendbuf, recvbuf, int root=0)
comm.Gatherv(sendbuf, recvbuf, int root=0)
comm.Allgather(sendbuf, recvbuf)
comm.Allgatherv(sendbuf, recvbuf)
comm.gather(sendobj=None, recvobj=None, int root=0)
comm.allgather(sendobj=None, recvobj=None)

Compared to the scatter methods, the roles of sendbuf and recvbuf are exchanged for Gather and Gatherv. In Gather sendbuf must contain the same number of elements in all tasks and the recvbuf on root must contain size times that number of elements, where size is the total number of tasks. For Gatherv the integer tuples counts and displacements characterize the layout of recvbuf, as described in the scatter section. Here sendbuf must contain exactly counts[rank] elements in task rank. The following code demonstrates this.

a_size = 4
recvdata = None
senddata = (rank+1)*numpy.arange(a_size,dtype=numpy.float64)
if rank == 0:
   recvdata = numpy.arange(size*a_size,dtype=numpy.float64)
print 'on task',rank,'after Gather:    data = ',recvdata 

if rank == 0:
   recvdata = numpy.empty(12,dtype=numpy.float64)
sendbuf = [senddata,counts[rank]]
recvbuf = [recvdata,counts,dspls,MPI.DOUBLE]
print 'on task',rank,'after Gatherv:    data = ',recvdata

The lower case function gather communicates generic python data objects analogous to the scatter function. An example is

senddata = ['rank',rank]
rootdata = comm.gather(senddata,root=0)
print 'on task',rank,'after bcast:    data = ',rootdata

The “all” variants of the gather methods deliver the collected data not only to the root task, but to all tasks in the communicator. These methods therefore lack the root parameter.


alltoall operations combine gather and scatter. In a communicator with size tasks every task has a sendbuf and a recvbuf with exactly size data objects. The alltoall operation takes the i-th object from the sendbuf of task j and copies it into the j-th object of the recvbuf of task i. The operation can be thought of as a transpose of the matrix with tasks as columns and data objects as rows. The syntax of the alltoall methods is

comm.Alltoall(sendbuf, recvbuf)
comm.Alltoallv(sendbuf, recvbuf)
comm.alltoall(sendobj=None, recvobj=None)

The data objects in sendbuf and recvbuf have types depending on the method. In Alltoall the data objects are equally sized consecutive sections of buffer like objects. In Alltoallv they are sections of varying sizes and varying displacements of buffer like objects. The layout must be described the in counts und diplacements tuples, which have to be defined for sendbuf and recvbuf in every tasks in a way consistent with the intended transposition in the (task,object) matrix. Finally in the lower case alltoall function the data objects can be of any allowed Python type, provided that the data objects in sendbuf conform to those in recvbuf, which they will replace.

An example for Alltoall is

a_size = 1
senddata = (rank+1)*numpy.arange(size*a_size,dtype=numpy.float64)
recvdata = numpy.empty(size*a_size,dtype=numpy.float64)

Next an example for alltoall, to be started with two tasks.

data0 = ['rank',rank]
data1 = [1,'rank',rank]
print 'on task',rank,'    senddata = ',senddata
recvdata = comm.alltoall(senddata)
print 'on task',rank,'    recvdata = ',recvdata

Global Data Reduction

The data reduction functions of MPI combine data from all tasks with one of a set of predefined operations and deliver the result of this “reduction” to the root tsks or to all tasks. mpi4py provides the following operations for reduction:

MPI.MIN        minimum
MPI.MAX        maximum
MPI.SUM        sum
MPI.PROD       product
MPI.LAND       logical and
MPI.BAND       bitwise and
MPI.LOR        logical or
MPI.BOR        bitwise or
MPI.LXOR       logical xor
MPI.BXOR       bitwise xor
MPI.MAXLOC     max value and location
MPI.MINLOC     min value and location

The reduction operations need data of the appropriate type.


The syntax for the reduction methods is

comm.Reduce(sendbuf, recvbuf, op=MPI.SUM, root=0)
comm.Allreduce(sendbuf, recvbuf, op=MPI.SUM)
comm.reduce(sendobj=None, recvobj=None, op=MPI.SUM, root=0)
comm.allreduce(sendobj=None, recvobj=None, op=MPI.SUM)

The followimg example shows the use of Reduce and Allreduce. sendbuf and recvbuf must be buffer like data objects with the same number of elements of the same type in all tasks. The reduction operation is performed elementwise using the corresponding elements in sendbuf in all tasks. The result is stored into the corresponding element of recvbuf in the root task by Reduce and in all tasks by Allreduce. If the op paramter is omitted, the default operation MPI.SUM is used.

a_size = 3
recvdata = numpy.zeros(a_size,
senddata = (rank+1)*numpy.arange(a_size,
print 'on task',rank,'after Reduce:    data = ',recvdata

print 'on task',rank,'after Allreduce:    data = ',recvdata

The use of the lower case methods reduce and allreduce operating on generic python data objects is limited, because the reduction operations are undefined for most of the data objects (like lists, tuples etc.).


The reduce_scatter functions operate elementwise on size sections of the buffer like data objects sendbuf. The sections must have the equal number of elements in all tasks. The result of the reductions in section i is copied to recvbuf in task i, which must have an appropriate length. The syntax for the reduction methods is

comm.Reduce_scatter_block(sendbuf, recvbuf, op=MPI.SUM)
comm.Reduce_scatter(sendbuf, recvbuf, recvcounts=None, op=MPI.SUM)

In Reduce_scatter_block the number of elements in all sections must be equal and the number of elements in sendbuf must be size times that number. An example code is the following


a_size = 3
recvdata = numpy.zeros(a_size,
senddata = (rank+1)*numpy.arange(size*a_size,
print 'on task',rank,'senddata  = ',senddata
print 'on task',rank,'recvdata = ',recvdata

In Reduce_scatter the number of elements in the sections can be different. They must be given in the integer tuple recvcounts. The number of elements in sendbuf must be sum of the numbers of elements in the sections. On task i recvbuf must have the length of section i of sendbuf. The following code gives an example for this.


recv_size = range(1,size+1)
recvdata = numpy.zeros(recv_size[rank],
send_size = 0
for i in  range(0,size):
   send_size =send_size + recv_size[i]
senddata = (rank+1)*numpy.arange(send_size,
print 'on task',rank,'senddata  = ',senddata
print 'on task',rank,'recvdata = ',recvdata

Reduction with MINLOC and MAXLOC

The reduction operations MINLOC and MAXLOC differ from all others: they return two results, the minimum resp. maximum of the values in the different tasks and the rank of a task, which holds the extreme value. mpi4py provides the two operations only for the lower case reduce and allreduce mehods for comparing a single numerical data object in every task. An example is given in

inp = numpy.random.rand(size)
senddata = inp[rank]
print 'on task',rank,'reduce:    ',senddata,recvdata 

print 'on task',rank,'allreduce: ',senddata,recvdata

Code Examples

The python codes for all examples described in this tutorial are available from

Scientific Computing

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies