[NSWI004] [Teachers at NSWI004] Preemptive Scheduling

[Vojtech Horky]

Hello,

I am sending reply to the public mailing-list too.

Dne 04. 12. 20 v 15:12 Krisztian Bokor napsal(a):
> In the exc.c file, in the handle_exception_general() function, we have 
> to tell the scheduler to schedule the next thread: however, since we 
> also want this thread scheduled again, can we just use thread_yield() 
> instead of scheduler_add_ready_thread() and scheduler_schedule_next()?

Strictly speaking, the thread is not yielding as thread_yield() suggests 
that the thread gave up processor voluntarily. From this point of view, 
schedule_next() seems a more logical choice (and note that you can keep 
the thread ready even when it is rescheduled).

In a typical implementation, the overall result would be the same as 
thread_yield() calls schedule_next() anyway.

Furthermore, one can say that in an exception handler, no thread is 
actually executing as its code (that does real work) is no longer running.


> Also, what is the proper approach: should we use the 
> timer_interrupt_after(KERNEL_SCHEDULER_QUANTUM) function call right 
> before the thread_switch_to() call in the scheduler_schedule_next() 
> function? I suppose the quantums the tests give are always big enough so 
> that the timer interrupt does not trigger during the context switch, 
> correct?

During the critical part of the context switch, interrupts are disabled.

However, it makes a good sense to set the quantum just before the 
context switch (call to thread_switch_to) to give the newly scheduled 
thread the whole quantum.

As a side note: in certain cases it even makes sense to reset the 
quantum - i.e. boost the thread - after locking a mutex, for example. It 
helps to ensure that the thread passes the whole critical section in one
quantum. But it can have adverse effects too ;-).

Hope this helps,
- VH