I don't understand 1 thing though and would appreciate your comments.
Â
In various interfaces, like network sockets, or threads waiting for data from somewhere, there are various solutions based on _not_ checking the state of the socket or some sort of  queue continuously, but sort of getting _interrupted_ when there is data around, or like condition variables for threads.
I am not very clear on these points, but it seems that in these contexts, continuous polling is avoided and so actual CPU usage is usually not close to 100%.
Â
Why can't something similar be implemented with broadcast for e.g.?
Â
-----Original Message-----
From: "Jeff Squyres" [jsquyres_at_[hidden]]
Date: 13/12/2010 03:55 PM
To: "Open MPI Users"
Subject: Re: [OMPI users] curious behavior during wait for broadcast: 100% cpu
I think there *was* a decision and it effectively changed how sched_yield() effectively operates, and that it may not do what we expect any more.
See this thread (the discussion of Linux/sched_yield() comes in the later messages):
http://www.open-mpi.org/community/lists/users/2010/07/13729.php
I believe there's similar threads in the MPICH mailing list archives; that's why Dave posted on the OMPI list about it.
We briefly discussed replacing OMPI's sched_yield() with a usleep(1), but it was shot down.
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}