[haiku-development] Re: The new locking primitives and boosting -- I need some guidance here :)

On Thu, Jun 26, 2008 at 01:42, André Braga <meianoite@xxxxxxxxx> wrote:
> Be itself didn't implement this strategy
> because it was not necessary on BeOS, which related priorities to
> processing roles in a well-defined manner.

BTW, those priorities as defined by Be don't work too well when using
a fair scheduler. Consider:
B_NORMAL_PRIORITY   10
B_DISPLAY_PRIORITY   15
B_URGENT_DISPLAY_PRIORITY   20

A fair, priority-based scheduler would schedule a thread with
B_NORMAL_PRIORITY half as many times as another thread with
B_URGENT_DISPLAY_PRIORITY, because the ratios among their numeric
priorities is 1:2. We know pretty well that those are *not* the
semantics we desire when we spawn threads using those priorities.

So our options are to go the Linux route and base the fairness on CPU
usage (and there are signs that this _doesn't_work_well_); try and
manage to implement branding (a.k.a. subsystem-based priority
inheritance) in order to boost threads that are supposed to be very
responsive; or give up on the goal of having a fair scheduler and go
back to using a static, sorted-by-priority-based scheduler like the
one in BeOS.



Aye.


A.

Other related posts: