[Mpi3-rma] RMA Example 11.10

[Marc-Andre Hermanns]

Pavan,

comments and questions inline.

> On 06/12/2013 03:15 AM, Marc-Andre Hermanns wrote:
>> I was just reading the RMA chapter to understand the semantics of the
>> new calls. I came across Example 11.10 (page 459) and I think I'd need
>> some clarification.
>>
>> Does the local store not show in the public window because it is not
>> wrapped in an access epoch?
>
> Correct.  In the separate model, the MPI implementation may copy the
> public window into the private window (possibly in software) on an
> MPI_WIN_LOCK, thus losing that change to X.
>
>> Would it be the same in unified mode?
>
> Yes.  In the unified model, the change to X will not be lost, but the
> GET might not get the value yet, because the WIN_LOCK might not do a
> memory barrier (or at least a store fence).

Thanks for the clarification.

>> On a side note:
>> The example spans process B's access epoch over a call to MPI_Barrier.
>> Doesn't this bear the danger of a deadlock?
>
> Why will this deadlock?  MPI_WIN_LOCK cannot block for uncontended locks.

Yes. If the example is just a two-process run, then the lock will not be 
contended, and everything will be fine.

But what if a reader sees this code snippet not as a two-process example 
but as a two-process snapshot in a multi-process example, where the 
other processes are just not shown.

And if there are other processes involved, there could be contention on 
the lock, and there is not way for process B to know this in advance.

The whole thing feels a little bit like dining philosophers, where it is 
not such a good idea to block a resource while you are waiting for another.

>> Consider a process C that has the same calling sequence as process B. If
>> C get's the lock granted in MPI_Lock and process B's call to MPI_Lock
>> blocks to wait for the lock to be granted, C will never release the
>> lock, as it waits for process B to join the barrier. B, however, waits
>> for the lock and will never enter the barrier.
>
> They are all using SHARED lock.

Oops. I missed that. Sorry for that.

Then let's change the process C to have an exclusive lock. ;-)

My point here is not that this specific code snippet will deadlock. My 
point is more whether overlapping locks with barriers, is a good example 
of software engineering and we would like to have people to copy-paste 
this style. The focus of the example is on the 'store X' not the 
lock/barrier overlap, so the overlap might still be seen as a 'good 
thing to do'. Thinking of the philosophers again, I am not so convinced 
that this is so.

As my primary question is answered (thank you for that), we can take 
this second topic off the list and discuss some more ;-)

Cheers,
Marc-Andre
-- 
Marc-Andre Hermanns
German Research School for
Simulation Sciences GmbH
c/o Laboratory for Parallel Programming
52062 Aachen | Germany

Tel +49 241 80 99753
Fax +49 241 80 6 99753
Web www.grs-sim.de

Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
Registered in the commercial register of the local court of
Düren (Amtsgericht Düren) under registration number HRB 5268
Registered office: Jülich
Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt