[Mpi-forum] Missing MPI primitives - Probe+Wait
Solt, David George
david.solt at hp.com
Mon Apr 19 15:50:28 CDT 2010
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.
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
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
More information about the mpi-forum