This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Jeff Squyres wrote:
>It would be very strange for nanosleep to cause a problem for Open MPI -- it shouldn't interfere with any of Open MPI's mechanisms. Double check that your my_barrier() function is actually working properly -- removing the nanosleep() shouldn't affect the correctness of your barrier.
I read Gijsbert's e-mail differently. Apparently, the issue is not
MPI/OMPI at all, but a hang inside nanosleep.
>On Dec 31, 2009, at 1:15 PM, Gijsbert Wiesenekker wrote:
>>I only recently learned about the OMPI_MCA_mpi_yield_when_idle variable, I still have to test if that is an alternative to my workaround.
mpi_yield_when_idle does not free the CPU up very much. It still polls
fairly aggressively, and the yield() call doesn't really free the CPU up
that much. It's a weak and probably ungratifying solution for your problem.
>>Meanwhile I seem to have found the cause of problem ...
>>... rather than OpenMPI being the problem, nanosleep is the culprit because the call to it seems to hang.
So, "we" (OMPI community) are off the hook? Problem is in nanosleep?
"We" are relieved (or confused about what you're reporting)!