¿Cómo libero un boost :: mpi :: request?

Estoy tratando de hacer que MPI desconecte un comunicador, que es un asunto difícil: he creado una demostración a continuación. Tengo dos versiones de la misma idea, escuchando un int, una usando MPI_IRecv y una usando boost :: mpi :: request.

Notará que cuando use mpiexec -n 2 en este progtwig, la versión A se desconectará y saldrá felizmente, pero la versión B no. ¿Hay algún truco para MPI_Request_free-ing a boost :: mpi :: request? Esa parece ser la diferencia aquí. Si importa, estoy usando MSVC y MSMPI, y Boost 1.62.

#include "boost/mpi.hpp" #include "mpi.h" int main() { MPI_Init(NULL, NULL); MPI_Comm regional; MPI_Comm_dup(MPI_COMM_WORLD, &regional); boost::mpi::communicator comm = boost::mpi::communicator(regional, boost::mpi::comm_attach); if (comm.rank() == 1) { int q; //VERSION A: // MPI_Request n; // int j = MPI_Irecv(&q, 1, MPI_INT, 1, 0, regional, &n); // MPI_Cancel(&n); // MPI_Request_free(&n); //VERSION B: // boost::mpi::request z = comm.irecv(1, 0, q); // z.cancel(); } MPI_Comm_disconnect(&regional); MPI_Finalize(); return 0; } 

¿Encontré un error? Dudo que esté metido en el código.

Bueno, supongo que no es un error si está documentado: MPI_Request_free no es compatible con Boost.MPI .

Ahora volviendo al propio MPI:

Una llamada a MPI_CANCEL marca para cancelar una operación de comunicación pendiente, sin locking (enviar o recibir). La llamada de cancelación es local. Vuelve inmediatamente, posiblemente antes de que la comunicación sea cancelada. Aún es necesario llamar a MPI_REQUEST_FREE , MPI_WAIT o MPI_TEST (o cualquiera de las operaciones derivadas) con la solicitud cancelada como argumento después de la llamada a MPI_CANCEL . Si una comunicación está marcada para su cancelación, entonces se garantiza que se devolverá una llamada MPI_WAIT para esa comunicación, independientemente de las actividades de otros procesos (es decir, MPI_WAIT comporta como una función local);

Eso significa, simplemente:

 z.cancel(); z.wait(); 

y deberías estar bien

Ahora, en mi humilde opinión, esto es un mal desperdicio de RAII adecuado por Boost.MPI.