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

[Dave Goodell]

On Apr 20, 2010, at 3:27 AM, N.M. Maclaren wrote:

> I don't know how well you (or others) know POSIX threads and how they
> are implemented, or other threading interfaces, but the assumption  
> that
> you can write portable code is completely false.  For example, POSIX
> contains no specification of how non-memory actions (including almost
> everything that happens inside a library call) can be synchronised.   
> FAR
> worse are the number of facilities that are neither thread-neutral nor
> thread-specific (signals is the extreme case, but even network I/O is
> often like that, and MPI rather relies on it).

As Bill pointed out, this isn't something that MPI can solve.  These  
are shortcomings of pthreads (it provides only heavyweight  
synchronization with lots of implementation wiggle room) and the C  
language (it lacks a memory model and any notion of multiple threads).

> Incidentally, the second paragraph of 2.9.2 is false.  If only it were
> that simple :-(


Quoted for the list's benefit:
-------8<-------
In multithreaded environments, users can avoid conflicts between  
signals and the MPI library by catching signals only on threads that  
do not execute MPI calls. High quality single-threaded implementations  
will be signal safe: an MPI call suspended by a signal will resume and  
complete normally after the signal is handled.
-------8<-------

Perhaps it should be an "Advice to users", but I don't think that the  
paragraph is universally false.  I think the multithreading bit is/was  
accurate for some platforms (Solaris threads maybe?), as long as you  
jump through some hoops and sigwait.  It will also depend on the  
particular signals involved.

Do you have a suggestion for how this paragraph could be improved?

-Dave