Eugene Loh wrote:
> Jeff Squyres wrote:
>> On Sep 2, 2008, at 7:25 PM, Vincent Rotival wrote:
>>> I think I already read some comments on this issue, but I'd like to
>>> know of latest versions of OpenMPI have managed to solve it. I am
>>> now running 1.2.5
>>> If I run a MPI program with synchronization routines (e.g.
>>> MPI_barrier, MPI_bcast...), all threads waiting for data are still
>>> burning CPU. On the other hand when using non-blocking receives all
>>> threads waiting for data are not consuming any CPU.
>>> Would there be a possibility to use MPI_Bcast without burning CPU
>>> power ?
>> I'm afraid not at this time. We've talked about adding a blocking
>> mode for progress, but it hasn't happened yet (and is very unlikely
>> to happen for the v1.3 series).
> I'd like to understand this issue better.
> What about the variable mpi_yield_when_idle ? Is the point that this
> variable will cause a polling process to yield, but if there is no one
> to yield to then the process resumes burning CPU? If so, I can
> imagine this solution being sufficient in some cases but not in others.
> Also, Vincent, what do you mean by waiting threads not consuming any
> CPU for non-blocking receives? In what state are these threads? Are
> they in an MPI call (like MPI_Wait)? Or, have they returned from an
> MPI call (like MPI_Irecv) and the user application can then park these
> threads to the side?
The solution I retained was for the main thread to isend data separately
to each other threads that are using Irecv + loop on mpi_test to test
the finish of the Irecv. It mught be dirty but works much better than
> users mailing list