Nikita Danilov wrote:
Howard Chu writes:
[...]
>
> A straightforward reading of the language here says the decision happens
> "when pthread_mutex_unlock() is called" and not at any later time. There
> is nothing here to support your interpretation.
> >
> > I think the intention of the wording is that for deterministic policies,
> > it is clear that the waiting threads are actually worken and reevaluated
> > for scheduling. In the case of SCHED_OTHER, it means basically nothing,
> > considering the scheduling policy is arbitrary.
> >
> Clearly the point is that one of the waiting threads is waken and gets
> the mutex, and it doesn't matter which thread is chosen. I.e., whatever
Note that this behavior directly leads to "convoy formation": if that
woken thread T0 does not immediately run (e.g., because there are higher
priority threads) but still already owns the mutex, then other running
threads contending for this mutex will block waiting for T0, forming a
convoy.
I just wonder - what is the problem with this convoy formation?
It can only happen when the cpu is overloaded, and in that case
someone has to wait. In this case, the mutex waiters.
Aggressively handing the cpu to whoever holds a mutex will mean the
mutexes are free more of the time - but it will *not* mean less waiting in
tghe system. You just changes who waits.
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]
