[Mpi3-rma] Next RMA Telecon

[Jim Dinan]

I've updated ticket #283 with a table of data types for 
MPI_Win_get/set_attr:

https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283

It turns out that these are actually somewhat defined in the standard 
text (even for the new types), but it requires a careful/creative 
reading of the text.  We could get away without this ticket, but I think 
that it's a a good clarification.

The Fortran types all have to be INTEGER (KIND=MPI_ADDRESS_KIND) because 
of the function definition for get/set_attr.  The C types vary as shown 
in the table.

Please send any feedback.  I'll put this into Latex for the next meeting.

  ~Jim.

On 12/9/11 5:39 PM, Torsten Hoefler wrote:
> Hello Again,
>
> I created ticket #308 and #309 (I'm not 100% convinced by #309). Please
> comment as appropriate.
>
> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/308
> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/309
>
> I also removed win_lock_all(exclusive) from #284.
>
> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/284
>
> I also talked to Marc and he explained that the idea was that the lock
> can essentially be implemented as nonblocking (blocking at first use).
> However, together with local buffering (the first n puts may be
> nonblocking and the n-th put may block after the buffer is exhausted),
> this could create arbitrary blocking RMA operations (from a user's
> perspective). Marc agreed that this may be hard to program. So this
> functionality was clearly intended but the consequences may not be and
> this issue may need to be fixed.
>
> He will look into this in detail and get back to us.
>
> Thanks&  Best,
>    Torsten
>
>> The telecon ended after 1.5 hours and I'm summarizing our discussions
>> and decisions below:
>>
>>> 1) Adam's suggestion that datatype offsets have to be relative to MPI_BOTTOM
>> - Torsten creates a ticket to remove this sentence
>>
>>> 2) disp_unit should not be fixed (one can create one window for each)
>> - this issue was resolved and the comment will be ignored by Adam's
>>    advice
>>
>>> 3) allocate_shared proposal with MPI_Win_lock_all(exclusive)
>> - remove MPI_Win_lock_all(exclusive) from the proposal and re-read
>>
>>> 4) ticket 300: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/300
>> - Torsten will talk to Marc and report back
>>
>>> 5) ticket 283: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283
>> - Jim will bring a full proposal forward
>>
>>> 6) Adam suggested: p23, 6-7 Regarding status, we should either say that
>>>     all fields are undefined (except for the error) or we should specify
>>>     all values, e.g., what about values returned for MPI_GET_COUNT,
>>>     MPI_GET_ELEMENTS, or MPI_TEST_CANCELLED? Replace "The values of the
>>>     MPI_SOURCE and MPI_TAG fields are undefined." with "All other fields
>>>     in status are undefined." -- Question: Would it be useful to set
>>>     fields for count and get elements?
>> - Torsten will create a ticket to clarify that everything that is not
>>    explicitly specified remains undefined (similar to I/O)
>>
>> Comments are welcome!
>>
>> Thanks&  Best,
>>    Torsten
>>
>> --
>>   bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
>> Torsten Hoefler         | Performance Modeling and Simulation Lead
>> Blue Waters Directorate | University of Illinois (UIUC)
>> 1205 W Clark Street     | Urbana, IL, 61801
>> NCSA Building           | +01 (217) 244-7736
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>>
>