Dan, I guess this info key would apply to a Session? I can imagine an assertion saying that you'll never block on communication, i.e., no blocking send/recv and no wait, unless you are sure it completes, to make sure you're not creating a blocking dependency. That is the scope you have control over over. This would allow an implementation to take this particular session out of the global progress scope (progress on the WPM or other sessions). A wait test with requests from that session would still require global progress though to resolve any dependencies from sessions that do not carry this assert or from the WPM. If all sessions carry this assert then of course it's only WPM communication that has to be progressed (if any). Would that be useful? Thanks Joseph On 10/27/21 12:16 PM, Dan Holmes via mpiwg-sessions wrote:
Hi all,
During the HACC WG call today, we discussed whether progress can be isolated by session. We devised this simple pseudo-code example (below) that shows the answer is “no”. With current progress rules in MPI-4.0 (unchanged from previous versions of MPI), the code must not deadlock at the place(s) indicated by the comments, even with one thread of execution, because the MPI_Recv procedure at process 0 must progress the send operation from process 0, which means the MPI_Recv procedure at process 1 is required to complete.
If MPI is permitted to limit the scope of progress during the MPI_Recv procedure to just the operations within a particular session, then it is permitted to refuse to progress the send operation from process 0 and deadlock inevitably ensues, unless the two libraries use different threads or MPI supports strong progress (both of which are optional).
We suggested an INFO assertion that would give the user the opportunity to assert that they would not code the application in a way that resulted in this kind of deadlock. It might be hard for the user to know for sure when it is safe to use such an INFO assertion, especially in the general case and with opaque/closed-source libraries. However, if the INFO assertion was supplied, MPI could be implemented with separated/isolated progress. The scope of progress is global (whole MPI process) at the moment — and that would have to be the default scope/value for the INFO assertion. Smaller scopes could be session, communicator/window/file, and even operation.
Process 0:
library_A.begin_call -> {MPI_Issend(…, comm_A); }
library_B.begin_call -> {MPI_Recv(…, comm_B); } // deadlock ?
library_A.end_call -> {MPI_Wait(…, comm_A); }
library_B.end_call -> { }
Process 1:
library_A.begin_call -> {MPI_Recv(…, comm_A); } // deadlock ?
library_B.begin_call -> {MPI_Issend(…, comm_B); }
library_A.end_call -> { }
library_B.end_call -> {MPI_Wait(…, comm_B); }
Cheers, Dan. — Dr Daniel Holmes PhD Executive Director Chief Technology Officer CHI Ltd [email protected] <mailto:[email protected]>
_______________________________________________ mpiwg-sessions mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions