Hi Thomas,
as far as I know MPI does _not_ guarantee asynchronous progress
(unlike OpenSHMEM) because it would require some implementations to
start a progress thread.
Jeff has a nice blog post regarding this:
http://blogs.cisco.com/performance/mpi-progress
I was surprised to see this behavior i
On 06/29/15 17:25, Nathan Hjelm wrote:
This is not a configuration issue. On 1.8.x and master we use two-sided
communication to emulation one-sided. Since we do not currently have
async progress this requires the target to call into MPI to progress RMA
communication.
This will change in 2.x. I w
Hi Nathan,
> This is not a configuration issue. On 1.8.x and master we use two-sided
> communication to emulation one-sided. Since we do not currently have
> async progress this requires the target to call into MPI to progress RMA
> communication.
thanks for the clarification. Is there special ha
This is not a configuration issue. On 1.8.x and master we use two-sided
communication to emulation one-sided. Since we do not currently have
async progress this requires the target to call into MPI to progress RMA
communication.
This will change in 2.x. I will be adding a new component that does
Dear all,
I am currently investigating a microbenchmark with Open MPI 1.8.3 on
Infiniband and was wondering whether Open MPI provides target-side
progress for incoming lock requests.
It seems lock requests are only handled if the target calls into the
MPI API and I was wondering if that is a conf
