Re: sched_yield() makes OpenLDAP slow
From: Nick Piggin
Date: Sat Aug 20 2005 - 19:36:31 EST
Howard Chu wrote:
Lee Revell wrote:
On Sat, 2005-08-20 at 11:38 -0700, Howard Chu wrote:
> But I also found that I needed to add a new yield(), to work around
> yet another unexpected issue on this system - we have a number of
> threads waiting on a condition variable, and the thread holding the
> mutex signals the var, unlocks the mutex, and then immediately
> relocks it. The expectation here is that upon unlocking the mutex,
> the calling thread would block while some waiting thread (that just
> got signaled) would get to run. In fact what happened is that the
> calling thread unlocked and relocked the mutex without allowing any
> of the waiting threads to run. In this case the only solution was
> to insert a yield() after the mutex_unlock().
That's exactly the behavior I would expect. Why would you expect
unlocking a mutex to cause a reschedule, if the calling thread still
has timeslice left?
That's beside the point. Folks are making an assertion that
sched_yield() is meaningless; this example demonstrates that there are
cases where sched_yield() is essential.
The point is, with SCHED_OTHER scheduling, sched_yield() need not
do anything. It may not let any other tasks run.
The fact that it does on Linux is because we do attempt to do
something expected... but the simple matter is that you can't realy
on it to do what you expect.
I'm not sure exactly how you would solve the above problem, but I'm
sure it can be achieved using mutexes (for example, you could have
a queue where every thread waits on its own private mutex).... but I
don't do much userspace C programming sorry.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/