> .....
> If you take the position (not in the standard) that a generalized request
> completes in an MPI handler routine, such as in the example, then the MPI_WAIT
> can block, since it must wait for some MPI operation to complete. But if this
> restriction is made, I'm not sure that the generalized requests are
> appropriate for things like MPI-IO, where the actual operation may not involve
> MPI at all.
>
> Bill
I would certainly take the position that, once a user posted an MPI_WAIT, then
it must be the case that the call to MPI_REQUEST_MARK_COMPLETE that will
complete the request will occur in a handler for a pending communication. MPI
does not requires multithreading, and no progress will occur on the user
thread after a Wait is posted. On the other hand, handlers are guaranteed to
execute, once the matching communication occurs. If the user called
MPI_WAIT(request) and there is no posted communication and/or handler that can
complete the request than the code can deadlock.
Your remark raises another question, namely whether we want events other than
message arrival to trigger the execution of a handler. We are already
half-way there, since we put in an MPI_INOTIFY that will cause a request to be
completed when a child dies. Since we can post a handler with the request(s)
returned by MPI_INOTIFY, we have the ability to trigger an asynchronous
activity on notification. If we extend the list of events recoginzed by
MPI_INOTIFY
to include standard Posix signals, then we can now use asynchronous handlers
and generalized requests to deal with events that are communication events, as
well as events that are signals, without requiring MPI_WAIT to be spinning.
Marc Snir
IBM T.J. Watson Research Center
P.O. Box 218, Yorktown Heights, NY 10598
email: snir@watson.ibm.com
phone: 914-945-3204
fax: 914-945-4425
URL: http://www.research.ibm.com/people/s/snir