Probably while all of the processes are I the MPI stack waiting most of them are blocking on a mutex that will only let one of them into the MPI progress engine. Depending on how your application is architected, you could have just one thread make progress in MPI by calling Waitany and then just use Test or Testany in the other threads. Unless your using per object locking, you won't have multiple processes polling the network at the same time. 

Wesley

On Sep 27, 2014, at 7:39 AM, Anatoly G <anatolyrishon@gmail.com> wrote:

You are absolutely right.
But some engineer  designed to execute another application on computer while system is in ready state.
This application executed only when my application in ready state.
I'm not familiar with the reason, but currently this is a situation.
One more question:
My application designed not by me, then I can't explain you design reason for the solution.
I have number of communicators which are cloned from MPI_COMM_WORLD. I execute on each communicator MPI_Waitany on separate thread. The data mostly arrives on single communicator only, but other threads are just waiting. I mean that single thread is actually working with MPI, others are on busy wait. Do I have polling penalty in this case? 

Regards,
Anatoly.



On Tue, Sep 23, 2014 at 4:49 PM, Rob Latham <robl@mcs.anl.gov> wrote:


On 09/23/2014 09:38 AM, Wesley Bland wrote:

Out of curiosity, what is the issue with using 100% of the CPU? If
you’re not using it for your application (which it appears that you
aren’t since you’re calling MPI_Wait), what difference does it make if
MPI uses all of it?

 power consumption, I'd imagine.

==rob

--
Rob Latham
Mathematics and Computer Science Division
Argonne National Lab, IL USA

_______________________________________________
discuss mailing list     discuss@mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss

_______________________________________________
discuss mailing list     discuss@mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss