threaded and non-threaded MPI implementations. In version 1, you need
threads to make progress. In versions 2, you can only use
MPI_HANDLER_ENABLE/DISABLE when not on a thread-compliant MPI. They
all seem to require the use of the thread locking mechanisms when you
are on a threaded MPI and these are not standardized. The thread
query functions will allow one to see what is the thread status on
this implementation so the method can work in principle. We may need
to make the GRs nonportable but I think it should be a concious and up
front decision.
All the proposals acheive the goal of nonblocking operations where one
can do standard MPI operations (wait/test) to check on completion. In
that regard they are integrated into MPI. However, as stated above,
they are not going to allow one to implement a GR with one piece of
portable code. Given this and the one clear use of GR for I/O, I am
wondering if the more complex choices (versions 2) are a major
improvement over version 1 (Marc prefers version 1). If threads are
reasonably fair, then removing progress from MPI is likely to be ok.
Steve