[Mpi-forum] Missing MPI primitives - Probe+Wait

[Solt, David George]

Can you do an MPI_Iprobe + MPI_Waitall(iprobe request + other requests)?

Regarding "of the form that will yield to other threads and processes, not a spin loop" is currently considered and implementation artifact and it is up to a particular MPI implementation if they want to spin or block or yield or expose how waiting is handled to the user.

The 2nd request could be handled in a number of ways using current API's primitives, but would all require MPI_THREAD_MULTIPLE to be set.  I believe you will need to argue a strong case for why multiple threads should be able to simultaneously call any existing or desired MPI AI's without  MPI_THREAD_MULTIPLE set.  

Thanks,
Dave Solt

-----Original Message-----
From: mpi-forum-bounces at lists.mpi-forum.org [mailto:mpi-forum-bounces at lists.mpi-forum.org] On Behalf Of N.M. Maclaren
Sent: Monday, April 19, 2010 3:35 PM
To: Main MPI Forum mailing list
Subject: [Mpi-forum] Missing MPI primitives - Probe+Wait

I have been drafting a design for Fortran coarrays based on MPI, and have
hit a couple of rather critical missing primitives.

One is that I need to do a blocking wait (of the form that will yield to
other threads and processes, not a spin loop) that will terminate as soon
as either a message comes in (i.e. like MPI_Probe) or one of the outstanding
non-blocking messages completes (i.e. like MPI_Waitall).

Another is the ability to interrupt one of those primitives (or, I suppose,
MPI_Probe or one of the MPI_Waits) from another thread in the same process
in the case that MPI_THREAD_MULTIPLE is NOT set.  No message needed - just
a way of breaking out.

The first could easily be added by a pseudo-request that was satisfied by
the existence of an incoming message - obviously, the status would be
full of the usual 'unset' values - or by adding a separate function.
I doubt that it would be any trickier to implement than MPI_Waitany.

The second is easy to specify.  It would need a three-state return value:
success, not in a wait, or failure.  Allowing the last would make it
reliably implementable, though not ideal for my purposes :-(  I can see
how to implement it in most cases, so that opt-out should rarely be used.
But there are circumstances when it would be needed.

Any comments?  Including that I have been an idiot and missed something
obvious :-)


Regards,
Nick Maclaren.


_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum