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: [email protected] [mailto:[email protected]] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum