July 2014 - mpiwg-rma - mailman3.cels.anl.gov

Re: [mpiwg-rma] Memory barriers in passive-target RMA
by Balaji, Pavan 15 Jul '14

15 Jul '14

I should have clarified in my original email — I’m talking about the UNIFIED memory model. — Pavan On Jul 15, 2014, at 12:14 AM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: > The equivalent text in the standard is on pg 454, ln 25-29. > > "If a put or accumulate access was synchronized with a lock, then the update of the public window copy is complete as soon as the updating process executed MPI_WIN_UNLOCK or MPI_WIN_UNLOCK_ALL. In the RMA separate memory model, the update of a private copy in the process memory may be delayed until the target process executes a synchronization call on that window (6).” > > Rajeev > > On Jul 14, 2014, at 1:45 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> >> 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(a)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(a)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(a)mcs.anl.gov> wrote: >>>> >>>>> See example 11.8 on pg 458. >>>>> >>>>> Rajeev >>>>> >>>>> On Jul 14, 2014, at 1:15 PM, Balaji, Pavan <balaji(a)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(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>>> >>>>> _______________________________________________ >>>>> mpiwg-rma mailing list >>>>> mpiwg-rma(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>> >>>> _______________________________________________ >>>> mpiwg-rma mailing list >>>> mpiwg-rma(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>> >>> _______________________________________________ >>> mpiwg-rma mailing list >>> mpiwg-rma(a)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 (✉️). >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpiwg-rma] Memory barriers in passive-target RMA
by Thakur, Rajeev 15 Jul '14

15 Jul '14

The equivalent text in the standard is on pg 454, ln 25-29. "If a put or accumulate access was synchronized with a lock, then the update of the public window copy is complete as soon as the updating process executed MPI_WIN_UNLOCK or MPI_WIN_UNLOCK_ALL. In the RMA separate memory model, the update of a private copy in the process memory may be delayed until the target process executes a synchronization call on that window (6).” Rajeev On Jul 14, 2014, at 1:45 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > 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(a)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(a)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(a)mcs.anl.gov> wrote: >>> >>>> See example 11.8 on pg 458. >>>> >>>> Rajeev >>>> >>>> On Jul 14, 2014, at 1:15 PM, Balaji, Pavan <balaji(a)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(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>> >>>> _______________________________________________ >>>> mpiwg-rma mailing list >>>> mpiwg-rma(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>> >>> _______________________________________________ >>> mpiwg-rma mailing list >>> mpiwg-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)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 (✉️). > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] Memory barriers in passive-target RMA
by Balaji, Pavan 14 Jul '14

14 Jul '14

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(a)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(a)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(a)mcs.anl.gov> wrote: >> >>> See example 11.8 on pg 458. >>> >>> Rajeev >>> >>> On Jul 14, 2014, at 1:15 PM, Balaji, Pavan <balaji(a)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(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>> >>> _______________________________________________ >>> mpiwg-rma mailing list >>> mpiwg-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)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 (✉️).

1 0

Re: [mpiwg-rma] Memory barriers in passive-target RMA
by Thakur, Rajeev 14 Jul '14

14 Jul '14

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(a)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(a)mcs.anl.gov> wrote: > >> See example 11.8 on pg 458. >> >> Rajeev >> >> On Jul 14, 2014, at 1:15 PM, Balaji, Pavan <balaji(a)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(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

doodle poll for RMA working group telecon
by Thakur, Rajeev 14 Jul '14

14 Jul '14

We need to discuss a few tickets over telecon. Let us start with a telecon for ticket 437 that Rolf has created: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/437. It is to clarify whether remote accesses to shared memory are to be considered similar to RMA operations or local loads/stores. A few related tickets are linked there. Please indicate your availability in the weeks of July 21 and 28 in the doodle poll at http://doodle.com/hx3p4cbwfcyszam6. I have listed only a few slots on each day to accommodate European and Pacific time zones. Thanks, Rajeev

1 0

Re: [mpiwg-rma] Memory barriers in passive-target RMA
by Jeff Hammond 14 Jul '14

14 Jul '14

Ugh that fixes it but maybe you could just compose email in plain text instead :-) Sent from my iPhone > On Jul 14, 2014, at 2:36 PM, "Balaji, Pavan" <balaji(a)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(a)mcs.anl.gov> wrote: >> >> See example 11.8 on pg 458. >> >> Rajeev >> >>> On Jul 14, 2014, at 1:15 PM, Balaji, Pavan <balaji(a)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(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] Memory barriers in passive-target RMA
by Balaji, Pavan 14 Jul '14

14 Jul '14

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(a)mcs.anl.gov> wrote: > See example 11.8 on pg 458. > > Rajeev > > On Jul 14, 2014, at 1:15 PM, Balaji, Pavan <balaji(a)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(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] Memory barriers in passive-target RMA
by Thakur, Rajeev 14 Jul '14

14 Jul '14

See example 11.8 on pg 458. Rajeev On Jul 14, 2014, at 1:15 PM, Balaji, Pavan <balaji(a)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(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] Memory barriers in passive-target RMA
by Jeff Hammond 14 Jul '14

14 Jul '14

Can you resend without the awful HTML punctuation? =3D=3D is not easy to parse. Jeff Sent from my iPhone > On Jul 14, 2014, at 2:15 PM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: > > P0: > Win_lock(P1) > Put(X, 1) > Win_unlock(P1) > MPI_Send(P1) > > P1: > MPI_Recv(P0) > assert(X =3D=3D 1) > > If the above is correct, shouldn=92t there be a memory read barrier on P1 s= > omewhere? Since P1 is not making any RMA calls, I=92d assume that=92ll nee= > d to somehow come from the lock and unlock operations. That is, the MPI im= > plementation will need to do an active message in Win_lock and Win_unlock f= > orcing a memory barrier at the target. Assuming that=92s correct, I'll hav= > e 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=92m really hopin= > g that I missed something in the standard which will say I don=92t 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, > > =97 Pavan > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Memory barriers in passive-target RMA
by Balaji, Pavan 14 Jul '14

14 Jul '14

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

1 0