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