MPI 3.1 5.12 is pretty clear on the matter:
"It is erroneous to call MPI_REQUEST_FREE or MPI_CANCEL for a request
associated with a nonblocking collective operation."
-Nathan
> On Jun 9, 2017, at 5:33 AM, Markus wrote:
>
> Dear MPI Users and Maintainers,
>
> I am using openMPI in version 1.
Dear MPI Users and Maintainers,
I am using openMPI in version 1.10.4 with enabled multithread support and
java bindings. I use MPI in java, having one process per machine and
multiple threads per process.
I was trying to build a broadcast listener thread which calls MPI_iBcast,
followed by MPI_WA
Thank you very much for your comments. I worked around the problem so I
don't need MPI_Cancel anymore.
Hi slimtimmy
I have been involved in several of the MPI Forum's discussions of how
MPI_Cancel should work and I agree with your interpretation of the
standard. By my reading of the standard
Hi slimtimmy
I have been involved in several of the MPI Forum's discussions of how
MPI_Cancel should work and I agree with your interpretation of the
standard. By my reading of the standard, the MPI_Wait must not hang and the
cancel must succeed.
Making an MPI implementation work exactly as the
The MPI_Cancel is only supported for receive requests. It's a no-op
for sends. Therefore your request never get canceled and the wait will
block until the request completion ... which means it will block
forever (as there is no receive corresponding to the request).
george.
On Apr 15, 20
I encountered some problems when using MPI_CANCEL. I call
Request::Cancel followed by Request::Wait to ensure that the request has
been cancelled. However Request::Wait does not return when I send bigger
messages. The following code should reproduce this behaviour:
#include "mpi.h"
#include
usi
