[mpiwg-rma] Changes to the RMA chapter
Rob Latham
robl at mcs.anl.gov
Thu Mar 5 09:01:08 CST 2015
On 03/04/2015 08:35 PM, Jim Dinan wrote:
> I agree, no_locks seems to have a clear local semantic. accumulate_ops
> ad accumulate_ordering need some thought from the WG; I think these were
> intended to be provided at all processes.
if you are going to call it an MPI_Info, then please follow the rules of
MPI_Info objects already well established in the I/O chapter. all
processes must specify the same value for a given MPI_Info key.
RMA has "things that are like infos but don't follow info rules" they
are called "asserts", right?
==rob
>
> ~Jim.
>
> On Wed, Mar 4, 2015 at 6:26 PM, William Gropp <wgropp at illinois.edu
> <mailto:wgropp at illinois.edu>> wrote:
>
> Actually, I think the wording is clear - no process will target that
> particular window (not window object) with passive target
> synchronization. Thus, as noted in the description, no async
> handing for passive RMA is needed at this process. It says nothing
> about whether this process can issue locks against some other
> process’s window.
>
> Bill
>
> On Mar 4, 2015, at 5:17 PM, Balaji, Pavan <balaji at anl.gov
> <mailto:balaji at anl.gov>> wrote:
>
> >
> > If the intention is that it can be local, then the info needs to
> specify whether it means the process cannot issue locks or whether
> other processes cannot issue locks on it. Either way, some change
> is required. I agree this is not ticket-0, and will tell the Forum
> that the RMA WG will put it on the list of things to discuss. We
> should do a WG telecon. A number of issues are queued up for
> discussion at this point.
> >
> > -- Pavan
> >
> >> On Mar 4, 2015, at 5:09 PM, William Gropp <wgropp at illinois.edu
> <mailto:wgropp at illinois.edu>> wrote:
> >>
> >> For the bigger one, yes, this is much harder and absolutely not
> ticket-0. no_locks is particularly tricky, because it applies to
> the window, not the window object, and hence is defined as local.
> >>
> >> Bill
> >>
> >> On Mar 4, 2015, at 4:59 PM, Balaji, Pavan <balaji at anl.gov
> <mailto:balaji at anl.gov>> wrote:
> >>
> >>>
> >>> There are two questions below. The formatting part (whether to
> use [SAME]) is a smaller issue. The bigger issue is whether we want
> to say that all the remaining info keys no_locks, etc., should be
> the same on all processes.
> >>>
> >>> I want to say that, but: (1) need the chapter committee
> consensus, and (2) I'm not sure it's a ticket-0 change, though we
> did make that change for same_size as ticket-0.
> >>>
> >>> -- Pavan
> >>>
> >>>> On Mar 4, 2015, at 4:56 PM, William Gropp <wgropp at illinois.edu
> <mailto:wgropp at illinois.edu>> wrote:
> >>>>
> >>>> That’s an excellent idea - we should use the same language
> throughout the standard, and the I/O chapter is probably the best
> source.
> >>>>
> >>>> Bill
> >>>>
> >>>> On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji at anl.gov
> <mailto:balaji at anl.gov>> wrote:
> >>>>
> >>>>>
> >>>>> Nathan suggested to use the I/O chapter format where info
> keys are annotated with "[SAME]" to indicate that all processes must
> provide the same info key. That is probably a ticket-0 change. We
> need to first agree on whether we want to do this.
> >>>>>
> >>>>> -- Pavan
> >>>>>
> >>>>>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji at anl.gov
> <mailto:balaji at anl.gov>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Folks at Forum complained about the addition to the
> "same_size" info key which added the following phrase:
> >>>>>>
> >>>>>> "and that all processes have provided this info key with the
> same value"
> >>>>>>
> >>>>>> (this change was not a part of any ticket, and was made by
> the chapter committee)
> >>>>>>
> >>>>>> There were two concerns:
> >>>>>>
> >>>>>> 1. This is a backward incompatible change (as in,
> applications were not required to give the same value earlier),
> though folks understood why this is needed. They were OK as long as
> we add a Errata/Changelog item saying so.
> >>>>>>
> >>>>>> 2. The property that all processes should give the same info
> key was true for other keys in that section as well (no_locks,
> accumulate_ordering, accumulate_ops). So the same sentence should
> be added to them as well.
> >>>>>>
> >>>>>> The Forum wants to see a draft of these changes. I'd like
> to propose adding the same phrase ("and that all processes have
> provided this info key with the same value") to the other info keys
> as well. What do folks think? Is this something that we agree on
> (technically, it is possible to have different info keys in the job,
> but it probably doesn't make much sense).
> >>>>>>
> >>>>>> Thoughts?
> >>>>>>
> >>>>>> -- Pavan
> >>>>>>
> >>>>>> --
> >>>>>> Pavan Balaji ✉️
> >>>>>> http://www.mcs.anl.gov/~balaji
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> mpiwg-rma mailing list
> >>>>>> mpiwg-rma at lists.mpi-forum.org
> <mailto:mpiwg-rma at lists.mpi-forum.org>
> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
> >>>>>
> >>>>> --
> >>>>> Pavan Balaji ✉️
> >>>>> http://www.mcs.anl.gov/~balaji
> >>>>>
> >>>>> _______________________________________________
> >>>>> mpiwg-rma mailing list
> >>>>> mpiwg-rma at lists.mpi-forum.org
> <mailto:mpiwg-rma at lists.mpi-forum.org>
> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
> >>>>
> >>>> _______________________________________________
> >>>> mpiwg-rma mailing list
> >>>> mpiwg-rma at lists.mpi-forum.org
> <mailto:mpiwg-rma at lists.mpi-forum.org>
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
> >>>
> >>> --
> >>> Pavan Balaji ✉️
> >>> http://www.mcs.anl.gov/~balaji
> >>>
> >>> _______________________________________________
> >>> mpiwg-rma mailing list
> >>> mpiwg-rma at lists.mpi-forum.org
> <mailto:mpiwg-rma at lists.mpi-forum.org>
> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
> >>
> >> _______________________________________________
> >> mpiwg-rma mailing list
> >> mpiwg-rma at lists.mpi-forum.org <mailto:mpiwg-rma at lists.mpi-forum.org>
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
> >
> > --
> > Pavan Balaji ✉️
> > http://www.mcs.anl.gov/~balaji
> >
> > _______________________________________________
> > mpiwg-rma mailing list
> > mpiwg-rma at lists.mpi-forum.org <mailto:mpiwg-rma at lists.mpi-forum.org>
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org <mailto:mpiwg-rma at lists.mpi-forum.org>
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>
>
>
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>
--
Rob Latham
Mathematics and Computer Science Division
Argonne National Lab, IL USA
More information about the mpiwg-rma
mailing list