[Mpi-forum] Missing MPI primitives - Probe+Wait
goodell at mcs.anl.gov
Tue Apr 20 08:49:50 CDT 2010
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
> 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.
> 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:
In multithreaded environments, users can avoid conﬂicts 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.
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?
More information about the mpi-forum