David Schwartz wrote:
Robert Hancock wrote:
But the thread the released the
mutex is not one of the waiting threads, and is not eligible for
consideration.
Where are you getting this from? Nothing requires the scheduler to schedule
any threads when the mutex is released.
Correct.
All that must happen is that the mutex must be unlocked. The scheduler is
permitted to allow any thread it wants to run at that point, or no thread.
Nothing says the thread that released the mutex can't continue running and
Correct. The releasing thread may keep running.
nothing says that it can't call pthread_mutex_lock and re-acquire the mutex
before any other thread gets around to getting it.
Wrong.
The spec says that the mutex must be given to a waiter (if any) at the
moment of release. The waiter don't have to be scheduled at that
point, it may keep sleeping with its freshly unlocked mutex. So the
unlocking thread may continue - but if it tries to reaquire the mutex
it will find the mutex taken and go to sleep at that point. Then other
processes will schedule, and at some time the one now owning the mutex
will wake up and do its work.
In general, it is very bad karma for the scheduler to stop a thread before
its timeslice is up if it doesn't have to. Consider one CPU and two threads,
each needing to do 100 quick lock/unlock cycles. Why force 200 context
switches?
Good point, except it is a strange program that do this. Lock the mutex
once,
do 100 operations, then unlock is the better way. :-)
Helge Hafting
-
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]
