[Mpi3-ft] one sided

[Sur, Sayantan]

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: mpi3-ft-bounces at lists.mpi-forum.org [mailto:mpi3-ft-
> bounces at lists.mpi-forum.org] On Behalf Of Pavan Balaji
> Sent: Wednesday, October 19, 2011 9:05 AM
> To: mpi3-ft at lists.mpi-forum.org
> 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
> > <alexander.supalov at intel.com>  wrote:
> >> Thanks. Why not having two calls or modes of operation to cover
> both?
> >>
> >> -----Original Message-----
> >> From: mpi3-ft-bounces at lists.mpi-forum.org [mailto:mpi3-ft-
> bounces at lists.mpi-forum.org] 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
> >> mpi3-ft at lists.mpi-forum.org
> >> 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
> >> mpi3-ft at lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
> >>
> >>
> >
> >
> >
> 
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft