[mpich-discuss] Does MPICH implements polling mechanism on MPI_Recv?

[Wesley Bland]

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 at 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 at 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 at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
> 
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20140927/f362ed93/attachment.html>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss