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 [email protected]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
