From a926a9b4fbc0c7f42c6f39f79880c59b10a3eb8d Mon Sep 17 00:00:00 2001 From: Brian Barrett Date: Fri, 12 Aug 2005 15:21:59 +0000 Subject: [PATCH] * I'm sure any decent optimizing compiler would have figured this one out, but there's no point in having the call_yield check performed if we don't have sched_yield to call in the first place. This commit was SVN r6823. --- opal/runtime/opal_progress.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/opal/runtime/opal_progress.c b/opal/runtime/opal_progress.c index b78948bd7a..4857e32267 100644 --- a/opal/runtime/opal_progress.c +++ b/opal/runtime/opal_progress.c @@ -231,17 +231,17 @@ opal_progress(void) opal_atomic_unlock(&progress_lock); #endif /* OMPI_HAVE_THREAD_SUPPORT */ +#if !defined(WIN32) && defined(HAVE_SCHED_YIELD) if (call_yield && events <= 0) { /* If there is nothing to do - yield the processor - otherwise * we could consume the processor for the entire time slice. If * the processor is oversubscribed - this will result in a best-case * latency equivalent to the time-slice. */ -#if !defined(WIN32) && defined(HAVE_SCHED_YIELD) /* TODO: Find the windows equivalent for this */ sched_yield(); -#endif } +#endif }