[haiku-development] Re: Proposing kernel patch: mutexes/priorities
- From: clemens.zeidler@xxxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 02 Mar 2012 10:48:27 +1300
> Am 01.03.2012 21:33, schrieb Clemens Zeidler:
> > On Fri, 02 Mar 2012 05:43:09 +1300, Julian Harnath
> > <julian.harnath@xxxxxxxxxxxxxx> wrote:
> >> 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.
>
> I think the blocking high priority thread is not the problem, since
> it
> isn't scheduled while it is blocking. But other high priority threads
> may prevent the low priority thread from completing fast enough. It
> wouldn't help to lower the priority of the blocking thread.
>
> In any case, I don't think that the problem you describe is real. If
> it's holding a lock forever with low priority, then you are screwed
> regardless, when it means other threads waiting for the lock can't
> run. :-)
>
> But I better shut up now, I am pretty clueless with kernel stuff...
>
me too :) thanks all for the explanation! Thought the blocking thread
is scheduled too...
Clemens
Other related posts:
