[mpiwg-rma] Changes to the RMA chapter

[Jim Dinan]

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.

 ~Jim.

On Wed, Mar 4, 2015 at 6:26 PM, William Gropp <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> 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> 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> 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>
> 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> 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> 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
> >>>>>> 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
> >>>>> 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
> >>>
> >>> --
> >>> Pavan Balaji  ✉️
> >>> http://www.mcs.anl.gov/~balaji
> >>>
> >>> _______________________________________________
> >>> mpiwg-rma mailing list
> >>> 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
> >
> > --
> > Pavan Balaji  ✉️
> > http://www.mcs.anl.gov/~balaji
> >
> > _______________________________________________
> > mpiwg-rma mailing list
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20150304/2b7f9de6/attachment-0001.html>