[Mpi3-rma] MPI-3 UNIFIED model clarification

[Jeff Hammond]

Maybe the RMA WG should write a paper for
http://www.csm.ornl.gov/workshops/openshmem2013/ that explains why
passive polling on bytes is an indicator of a bad programming model
and how they should fix their semantics :-)

Jeff

On Wed, Jul 31, 2013 at 12:58 PM, Sur, Sayantan <sayantan.sur at intel.com> wrote:
>> On 07/31/2013 12:00 PM, Jim Dinan wrote:
>> > I would bet that past Jim suggested striking the polling/eventually
>> > visibile clause and relying on window synchronization to see updates.
>> >   :)
>>
>> Yup, so did past, present, and future Pavan.  IMO, that's a useless guarantee.
>>
>> > The downside to this is that libraries like SHMEM that rely on passive
>> > progress and polling, would not be implementable on top of Unified.
>>
>> It's pretty useless even for SHMEM, since the user doesn't know when the
>> data is valid.  You could poll on a byte for it to turn to one, but at that point
>> you only know about that one byte and nothing else.
>>
>
> Past Sayantan had missed this discussion, but present Sayantan does agree that "eventually" as defined is useless. But he is also confused by the guarantee given by MPI_Win_flush, that when the call returns, all previously issued RMA ops are complete locally and remotely + UNIFIED (public win == private win).
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma



-- 
Jeff Hammond
jeff.science at gmail.com