OMPI does use those methods, but they can't be used for something like shared memory. So if you want the performance benefit of shared memory, then we have to poll.


On Dec 13, 2010, at 9:00 AM, Hicham Mouline wrote:

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@cisco.com]
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.



_______________________________________________
users mailing list
users@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users