[haiku-development] Re: Scheduler algorithm improvements

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 28 Nov 2009 09:49:28 +0100

On 2009-11-27 at 16:18:46 [+0100], Mikhail Panasyuk <otoko@xxxxxxxxx> wrote:
[...]
> And there was another problem I've encountered and fixed. After thread 
> insertion into run queue which is based on thread->next_priority value 
> original scheduler does meaningless operation.
> 
> In scheduler_simple.cpp (102) and scheduler_affine.cpp (186):
> 
>     thread->next_priority = thread->priority;
>     
> Should be:
> 
>     thread->priority = thread->next_priority;
> 
> Also in scheduler_simple.cpp (122) and scheduler_affine.cpp (284):
> 
>         thread->priority = priority;
> 
> Should be:
> 
>         thread->priority = thread->next_priority = priority;
> 
> In some cases when next_priority and priority are not equal run queue 
> messes itself up, not sorted anymore. Original scheduler still kind of 
> "works" in such circumstances but mine is more picky because it 
> synchronises additional data structures with run queue and expects certain 
> things.
> 
> Can somebody please tell me what is the whole point of next_priority field 
> if it's not used anywhere for anything that priority field alone would be 
> enough for? There was no such field in NewOS...

I believe the idea is that when the thread is running only itself may alter 
thread::priority so that there are no surprising changes when the thread 
plays with its thread structure. Other threads should only set next_priority 
and when the thread is re-enqueued the priority field is updated. Obviously 
both schedulers' set_thread_priority() hooks do it exactly the wrong way and 
set the priority field instead of next_priority.

Anyway, it certainly wouldn't harm, if someone had a closer look at the uses 
of the thread::priority field to verify whether there really is a point to 
having a next_priority field.

CU, Ingo

Other related posts: