> Robert Hancock wrote:
> > "If there are threads blocked on the mutex object referenced by mutex
> > when pthread_mutex_unlock() is called, resulting in the mutex becoming
> > available, the scheduling policy shall determine which thread shall
> > acquire the mutex."
> >
> > This says nothing about requiring a reschedule. The "scheduling policy"
> > can well decide that the thread which just released the mutex can
> > re-acquire it.
> No, because the thread that just released the mutex is obviously not one
> of the threads blocked on the mutex.
So what?
> 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.
This is false and is nowhere found in the standard.
> 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.
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
nothing says that it can't call pthread_mutex_lock and re-acquire the mutex
before any other thread gets around to getting it.
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?
DS
-
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]
