Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: [OMPI users] Progress in MPI_Win_unlock
From: Dorian Krause (doriankrause_at_[hidden])
Date: 2010-02-03 19:24:01

Dear list,

from some small tests I ran it appears to me that progress in passive
target sided communication is only guaranteed if the origin issues some
"deeper" MPI function (i.e., a simple MPI_Comm_rank is not sufficient).
Can someone confirm this experimental observation?

I have two questions concerning this behavior:

a) Is this really standard conform? The MPI standard guarantees progress
of one-sided communication (if I understand the term "progress"
correctly ; the relevant page of the MPI 2.2 standard is 369). Unless it
is also specified that a process must eventually exit with a call to
MPI_Finalize (I couldn't find such a requirement), progress for RMA
access to a passive server which does not participate actively in any
MPI communication is not guaranteed, right?
(Btw. mvapich2 has the same behavior in this regard)

b) Is there any plan to change this behavior? I am working on an
application featuring a badly balanced load between processes. The idea
here was to use one-sided communication and hide the load-imbalance by
letting idle threads "work ahead" other threads. However, this assumes
that progress at these processes is independent of the target side.

Thanks for your help,

PS: I just took a look at "Analysis of Implementation Options for MPI-2
One-Sided" which answers some of my questions. Nevertheless I'm sending
the mail in hopes of triggering discussion about this.