Re: sched_yield() makes OpenLDAP slow

From: Robert Hancock
Date: Wed Jan 25 2006 - 09:38:44 EST


Howard Chu wrote:
No, because the thread that just released the mutex is obviously not one of the threads blocked on the mutex. When a mutex is unlocked, one of the *waiting* threads at the time of the unlock must acquire it, and the scheduling policy can determine that. But the thread the released the mutex is not one of the waiting threads, and is not eligible for consideration.

That statement does not imply that any reschedule needs to happen at the time of the mutex unlock at all, only that the other threads waiting on the mutex can attempt to reacquire it when the scheduler allows them to. In all likelihood, what tends to happen is that either the thread that had the mutex previously still has time left in its timeslice and is allowed to keep running and reacquire the mutex, or another thread is woken up (perhaps on another CPU) but doesn't reacquire the mutex before the original thread carries on and acquires it, and therefore goes back to sleep.

Forcing the mutex to ping-pong between different threads would be quite inefficient (especially on SMP machines), and is not something that POSIX requires.

--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@xxxxxxxxxxxxx
Home Page: http://www.roberthancock.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/