Rajeev
> Date: Tue, 25 Feb 1997 13:37:52 -0600 (CST)
> From: Steve Huss-Lederman <lederman@cs.wisc.edu>
>
> I will overlook the typos and example mistakes for now to focus on
> what I consider to be the bigger picture. Once we choose a method, we
> can fix up the text. I think airing our views before the next meeting
> is important since something will be done at this meeting.
>
> From my reading, none of Marc's proposals are portable between
> 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