<div dir="ltr">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. <div><br></div><div> ~Jim.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 4, 2015 at 6:26 PM, William Gropp <span dir="ltr"><<a href="mailto:wgropp@illinois.edu" target="_blank">wgropp@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Bill<br>
<div class="HOEnZb"><div class="h5"><br>
On Mar 4, 2015, at 5:17 PM, Balaji, Pavan <<a href="mailto:balaji@anl.gov">balaji@anl.gov</a>> wrote:<br>
<br>
><br>
> 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.<br>
><br>
>  -- Pavan<br>
><br>
>> On Mar 4, 2015, at 5:09 PM, William Gropp <<a href="mailto:wgropp@illinois.edu">wgropp@illinois.edu</a>> wrote:<br>
>><br>
>> 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.<br>
>><br>
>> Bill<br>
>><br>
>> On Mar 4, 2015, at 4:59 PM, Balaji, Pavan <<a href="mailto:balaji@anl.gov">balaji@anl.gov</a>> wrote:<br>
>><br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> -- Pavan<br>
>>><br>
>>>> On Mar 4, 2015, at 4:56 PM, William Gropp <<a href="mailto:wgropp@illinois.edu">wgropp@illinois.edu</a>> wrote:<br>
>>>><br>
>>>> That’s an excellent idea - we should use the same language throughout the standard, and the I/O chapter is probably the best source.<br>
>>>><br>
>>>> Bill<br>
>>>><br>
>>>> On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <<a href="mailto:balaji@anl.gov">balaji@anl.gov</a>> wrote:<br>
>>>><br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> -- Pavan<br>
>>>>><br>
>>>>>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <<a href="mailto:balaji@anl.gov">balaji@anl.gov</a>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> Folks at Forum complained about the addition to the "same_size" info key which added the following phrase:<br>
>>>>>><br>
>>>>>> "and that all processes have provided this info key with the same value"<br>
>>>>>><br>
>>>>>> (this change was not a part of any ticket, and was made by the chapter committee)<br>
>>>>>><br>
>>>>>> There were two concerns:<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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).<br>
>>>>>><br>
>>>>>> Thoughts?<br>
>>>>>><br>
>>>>>> -- Pavan<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Pavan Balaji  ✉️<br>
>>>>>> <a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> mpiwg-rma mailing list<br>
>>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>>><br>
>>>>> --<br>
>>>>> Pavan Balaji  ✉️<br>
>>>>> <a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> mpiwg-rma mailing list<br>
>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> mpiwg-rma mailing list<br>
>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>><br>
>>> --<br>
>>> Pavan Balaji  ✉️<br>
>>> <a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
>>><br>
>>> _______________________________________________<br>
>>> mpiwg-rma mailing list<br>
>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>><br>
>> _______________________________________________<br>
>> mpiwg-rma mailing list<br>
>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
><br>
> --<br>
> Pavan Balaji  ✉️<br>
> <a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
><br>
> _______________________________________________<br>
> mpiwg-rma mailing list<br>
> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
<br>
_______________________________________________<br>
mpiwg-rma mailing list<br>
<a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a></div></div></blockquote></div><br></div>