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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>>> >>>>> -- >>>>> Pavan Balaji ✉️ >>>>> http://www.mcs.anl.gov/~balaji >>>>> >>>>> _______________________________________________ >>>>> mpiwg-rma mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>> >>>> _______________________________________________ >>>> mpiwg-rma mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>> >>> -- >>> Pavan Balaji ✉️ >>> http://www.mcs.anl.gov/~balaji >>> >>> _______________________________________________ >>> mpiwg-rma mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> _______________________________________________ >> mpiwg-rma mailing list >> [email protected] <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > mpiwg-rma mailing list > [email protected] <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

_______________________________________________ mpiwg-rma mailing list [email protected] <mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

-- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA