[mpiwg-rma] Memory barriers in passive-target RMA

Balaji, Pavan balaji at anl.gov
Mon Jul 14 13:45:10 CDT 2014


Ah, you meant the caption, not the example itself.  Some equivalent text should go into the standard, since the example is non-binding.

  — Pavan

On Jul 14, 2014, at 1:41 PM, Thakur, Rajeev <thakur at mcs.anl.gov> wrote:

> On lines 40-42 it explains why the lock-unlock on process B is needed:
> 
> "Although the MPI_WIN_UNLOCK on process A and the MPI_BARRIER ensure that the public copy on process B reflects the updated value of X, the call to MPI_WIN_LOCK by process B is necessary to synchronize the private copy with the public copy.”
> 
> Rajeev
> 
> On Jul 14, 2014, at 1:36 PM, Balaji, Pavan <balaji at anl.gov> wrote:
> 
>> 
>> I don’t understand your point.  The example uses lock/unlock for local access, but that’s not a confirmation that it’s required.  It just means that you are allowed to use lock/unlock.
>> 
>> — Pavan
>> 
>> P.S.: Adding a unicode character to try to trick mac to use UTF-8.  Let’s see if this will work.  What the heck, apple?  ✉️
>> 
>> On Jul 14, 2014, at 1:30 PM, Thakur, Rajeev <thakur at mcs.anl.gov> wrote:
>> 
>>> See example 11.8 on pg 458.
>>> 
>>> Rajeev
>>> 
>>> On Jul 14, 2014, at 1:15 PM, Balaji, Pavan <balaji at anl.gov> wrote:
>>> 
>>>> 
>>>> The MPI standard seems to allow access to the local window without requiring a lock (at least, I couldn’t find any text requiring a lock).  Does this mean that the following example is correct?
>>>> 
>>>> P0:
>>>> 	Win_lock(P1)
>>>> 	Put(X, 1)
>>>> 	Win_unlock(P1)
>>>> 	MPI_Send(P1)
>>>> 
>>>> P1:
>>>> 	MPI_Recv(P0)
>>>> 	assert(X == 1)
>>>> 
>>>> If the above is correct, shouldn’t there be a memory read barrier on P1 somewhere?  Since P1 is not making any RMA calls, I’d assume that’ll need to somehow come from the lock and unlock operations.  That is, the MPI implementation will need to do an active message in Win_lock and Win_unlock forcing a memory barrier at the target.  Assuming that’s correct, I'll have to send out a lock packet even if the user gave the MPI_MODE_NOCHECK hint, for memory consistency reasons.  That sounds awful, so I’m really hoping that I missed something in the standard which will say I don’t need to do all this.
>>>> 
>>>> Note that all this active message problem will go away if I need P1 to do a lock/unlock to itself in order to access X.
>>>> 
>>>> Thanks,
>>>> 
>>>> — Pavan
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
>> _______________________________________________
>> 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

Unicode character to trick mac into using UTF-8 (✉️).


More information about the mpiwg-rma mailing list