Hi Wesley,
Thanks for the summary - I think this describes it fairly well.
One additional comment: there was some discussion on having to deal with
situations where there is/was an associated communicator, but that
communicator has been freed before the fault happened. The question was
which communicator an Abort should be on in this case. Personally, I think
it should propagate upwards to the next communicator in the hierarchy,
worst case to COMM_WORLD, but other options exist as well. It would be
good, though, to clearly define this case.
Martin
________________________________________________________________________
Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
On 6/1/15, 10:00 PM, "Bland, Wesley" <wesley.bland(a)intel.com> wrote:
>Notes from the ticket reading are now posted on the wiki:
>https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ftwg2015-06-01
>
>TL;DR - The reading did not ³pass², but we got lots of good feedback to
>come back with a new version. We should consider splitting this into two
>or three tickets. One to define new errhandlers that does the new
>definition (abort communicator) and one that¹s a more well defined old
>definition (abort MPI_COMM_WORLD). Another ticket will deprecate
>MPI_COMM_ERRORS_ARE_FATAL. Another ticket will consolidate the
>definitions of all of the error handling text to a single place.
>
>The rest of the details can be found in the wiki.
>
>I¹ll be working on some drafts over the next few days to try to get new
>versions of this ticket out for discussion. My tentative hope is to get
>this ready for a new plenary in September. There¹s going to be enough
>changes that this should probably get a plenary before another reading.
>
>Comments welcome.
>
>Thanks,
>Wesley
>_______________________________________________
>mpiwg-ft mailing list
>mpiwg-ft(a)lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft
I think propagating upwards is weird, and only there to work around poorly defined semantics at the cost of backward compatibility.
Take an application that makes a dup of MPI_COMM_WORLD, then changes the errhandler to MPI_ERRORS_RETURN. If this app then frees the dup communicator handle after issuing an MPI_Irecv, it would currently likely expect MPI_ERRORS_RETURN to be invoked if that receive encounters an error, rather than MPI_ERRORS_ARE_FATAL that exists on MPI_COMM_WORLD.
If an applications has a custom error handler that has per-communicator state, it would need to either:
- keep track of outstanding requests on the communicator before freeing the handle
- change the error handler to one of the built-in ones before freeing
- call MPI_COMM_DISCONNECT to ensure all pending communications are complete (with potential ramifications for anything < MPI_THREAD_MULTIPLE)
I think clarifying that an application that requires per-communicator context in their error handler and calls MPI_COMM_FREE before all pending operations are complete is erroneous is probably a better scoped solution - MPI has never provided any mechanism to notify the application of when a communicator is actually freed, and clearly defines that it may not be freed when MPI_COMM_FREE returns.
-Fab
-----Original Message-----
From: mpiwg-ft [mailto:[email protected]] On Behalf Of Schulz Martin
Sent: Tuesday, June 2, 2015 5:06 PM
To: MPI WG Fault Tolerance and Dynamic Process Control working Group
Subject: Re: [mpiwg-ft] Ticket 324 June 2015 Reading
Hi Wesley,
Thanks for the summary - I think this describes it fairly well.
One additional comment: there was some discussion on having to deal with
situations where there is/was an associated communicator, but that
communicator has been freed before the fault happened. The question was
which communicator an Abort should be on in this case. Personally, I think
it should propagate upwards to the next communicator in the hierarchy,
worst case to COMM_WORLD, but other options exist as well. It would be
good, though, to clearly define this case.
Martin
________________________________________________________________________
Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
On 6/1/15, 10:00 PM, "Bland, Wesley" <wesley.bland(a)intel.com> wrote:
>Notes from the ticket reading are now posted on the wiki:
>https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ftwg2015-06-01
>
>TL;DR - The reading did not ³pass², but we got lots of good feedback to
>come back with a new version. We should consider splitting this into two
>or three tickets. One to define new errhandlers that does the new
>definition (abort communicator) and one that¹s a more well defined old
>definition (abort MPI_COMM_WORLD). Another ticket will deprecate
>MPI_COMM_ERRORS_ARE_FATAL. Another ticket will consolidate the
>definitions of all of the error handling text to a single place.
>
>The rest of the details can be found in the wiki.
>
>I¹ll be working on some drafts over the next few days to try to get new
>versions of this ticket out for discussion. My tentative hope is to get
>this ready for a new plenary in September. There¹s going to be enough
>changes that this should probably get a plenary before another reading.
>
>Comments welcome.
>
>Thanks,
>Wesley
>_______________________________________________
>mpiwg-ft mailing list
>mpiwg-ft(a)lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft
_______________________________________________
mpiwg-ft mailing list
mpiwg-ft(a)lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft
Notes from the ticket reading are now posted on the wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ftwg2015-06-01
TL;DR - The reading did not “pass”, but we got lots of good feedback to come back with a new version. We should consider splitting this into two or three tickets. One to define new errhandlers that does the new definition (abort communicator) and one that’s a more well defined old definition (abort MPI_COMM_WORLD). Another ticket will deprecate MPI_COMM_ERRORS_ARE_FATAL. Another ticket will consolidate the definitions of all of the error handling text to a single place.
The rest of the details can be found in the wiki.
I’ll be working on some drafts over the next few days to try to get new versions of this ticket out for discussion. My tentative hope is to get this ready for a new plenary in September. There’s going to be enough changes that this should probably get a plenary before another reading.
Comments welcome.
Thanks,
Wesley
