[haiku-development] Re: Proposing kernel patch: mutexes/priorities

  • From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 1 Mar 2012 22:26:18 +0100

On Fri, Mar 02, 2012 at 09:33:34AM +1300, Clemens Zeidler wrote:
> On Fri, 02 Mar 2012 05:43:09 +1300, Julian Harnath
> <julian.harnath@xxxxxxxxxxxxxx> wrote:
> 
> >Hey!
> >
> >In relation to bug ticket 8007 [1] I propose a kernel patch (attached
> >to this mail) which implements:
> >* Kernel mutex waiting lists sorted by waiter priority (as opposed to
> >strict FIFO before)
> >* Priority boosting for kernel mutexes
> >* For the boosting to work, the thread struct keeps a list of mutexes
> >held by the thread
> >
> >The priority boosting works as follows: if a thread A with priority X
> >holds a mutex and another thread B with priority Y tries to acquire it,
> >and Y > X, then the priority of A gets temporarily boosted to Y+1. As
> >soon as A releases the mutex it gets back its old priority X. (except A
> >still holds more mutexes with higher-priority threads waiting.. then it
> >gets the priority of the next-highest-priority waiter plus one).
> >
> 
> sounds reasonable to me to solve this problem but maybe its even
> better to temporary reduce the priority of B to X-1? Otherwise you
> make A the super thread that might block the rest of the system for
> a very long time? E.g. A could hold the lock forever and thus do
> everything with the higher priority.

The idea is not that.
Thread B is a high priority thread, but it is prevented to run because
of low priority thread A, and has to wait for it. So, the idea is to get
thread A to finish as soon as possible so thread B can resume execution.
The solution is to raise priority of thread A. If you lower priority of
thread B, you don't solve anything, the thread is waiting on a mutex and
can't be scheduled anyway.

-- 
Adrien.

Other related posts: