Re: [Mpi3-ft] one sided
Thanks for the clarification, Josh. It makes sense to me.
-----Original Message----- From: [email protected] [mailto:mpi3-ft- [email protected]] On Behalf Of Josh Hursey Sent: Friday, October 21, 2011 2:28 PM To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group Subject: Re: [Mpi3-ft] one sided
Since MPI is creating a new communication object, we require that all processes have access to the object if it was created anywhere.
So consider if the 'win' object was created at some processes and not others. The application with the valid 'win' calls MPI_Win_fence(). Other processes in the group associated with the window will not be to call MPI_Win_fence since they do not have a valid object. The program is erroneous since not all processes are calling the collective. So the semantics become muddled when we talk about collective operations (even like MPI_Win_free) when not all processes are guaranteed to have a valid communication object to use.
So we just need the requirement that the object is either created everywhere or nowhere. Since we can only make statements about the behavior of MPI after the MPI_ERR_PROC_FAIL_STOP error code, we restrict the language to just that error code. Though it could be argued that this is a more general requirement, but that is slightly out of scope for this proposal.
Does that help clarify?
-- Josh
On Fri, Oct 21, 2011 at 4:54 PM, Sur, Sayantan <[email protected]> wrote:
Hi All,
The new chapter says this about the window creation:
"If the MPI_WIN_CREATE operation fails at any live process due to a process failure, then the operation must fail at every live process with an error in the class MPI_ERR_PROC_FAIL_STOP."
I'm wondering what would happen if MPI_WIN_CREATE did not have this qualification at all. i.e. it would succeed at some processes and fail at some processes. After all, any following GET or PUT calls can always raise the error class MPI_ERR_PROC_FAIL_STOP. Also, the communicator passed to MPI_WIN_CREATE is allowed to have dead processes in it ... then why qualify win create with this requirement?
Thanks, Sayantan.
-----Original Message----- From: [email protected] [mailto:mpi3-ft- [email protected]] On Behalf Of Pavan Balaji Sent: Wednesday, October 19, 2011 9:05 AM To: [email protected] Subject: Re: [Mpi3-ft] one sided
FYI, you cannot "require" some behavior from MPI through an info argument. It is perfectly legitimate for the MPI implementation to completely ignore any info arguments passed. They are just user hints.
� -- Pavan
On 10/19/2011 07:59 AM, Josh Hursey wrote:
Let's be sure to talk about this on today's call. I have some other one-sided notes that I would like to go over as well.
It would be fairly easy to support both modes since the MPI_Win_create operation takes an info argument. We could define a key (similar to what they have done for other operations) that either loosens or tightens the semantics depending on what the default behavior should be.
I think it is ok to have a non-synchronizing option, just as long as we have clear semantics for when the window is not created at all processes due to some process failure - or if the window is always created regardless of emerging failure then we might avoid this issue, but that might require some additional clarification.
Thanks, Josh
On Wed, Oct 19, 2011 at 4:11 AM, Supalov, Alexander <[email protected]> �wrote:
Thanks. Why not having two calls or modes of operation to cover both?
-----Original Message----- From: [email protected] [mailto:mpi3-ft- [email protected]] On Behalf Of Darius Buntinas Sent: Tuesday, October 18, 2011 9:57 PM To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group Subject: [Mpi3-ft] one sided
I got some feedback from Jim and Pavan on the one-sided section. One thing Jim pointed out was that we don't want to make window creation synchronizing, and the fail-or-succeed everywhere requirement would do that.
If we say that window creation should not fail due to failed processes, that would accomplish the same thing: �If a window is created by a correct program, then it will succeed at all live processes. �Note that if an incorrect program specifies invalid parameters then the window creation may fail at some processes and succeed at others, but this is what we already have today.
However, it's possible that some implementations cannot satisfy this requirement because, e.g., they do collectives as part of the operation. �So maybe we should have two options:
� Either: � � window creation won't fail because if failed processes � or � � window creation will either succeed or fail everywhere and if window creation fails at � � any process it fails at every process
-d
_______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft -----------------------------------------------------------------
------------------
Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
_______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
-- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
_______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
-- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey
_______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
participants (1)
-
Sur, Sayantan