Newsgroups: comp.parallel.mpi
From: dbc@ecs.soton.ac.uk (Bryan Carpenter)
Subject: MPI_PROBE nuisance
Organization: Electronics and Computer Science, University of Southampton
Date: 23 Nov 1994 17:34:23 -0000
Message-ID: <3avuev$lss@louis.ecs.soton.ac.uk>

I suppose this is a suitable forum for moaning about bits of MPI one
doesn't like.

MPI_PROBE is a blocking operation which terminates when a message (with
specified source and tag) is available to be received.  It sets a
status variable which can be interrogated to find characterestics of
the waiting message (length, etc).  The message can subsequently be
input with the normal MPI_RECV operation.  MPI_PROBE can be used to
accept messages whose characteristics aren't known in advance---for
example if no useful bound on the message length is known in advance
one can wait for it using MPI_PROBE, look up the size of the message,
dynamically allocate buffer space, then receive the message into that
space.

I have an application where it would be convenient to do something like
this.  Unfortunately I need to be outputting another message at the
same time as I'm waiting for incoming messages.  For any other blocking
operation there is a non-blocking variant with equivalent semantics
and an `I' in front of the name, which enables one to perform the
operation in parallel with something else.  In the case of MPI_PROBE,
there is an MPI_IPROBE, but it does something quite different to `I'
variants of other blocking operations, and I don't think there's any
sensible way to do what I want to do.

Is there a good reason for this?


Bryan


