devc1 wrote:
Quote:
Is preemption the fact that a thread does not run its full time burst because another higher priority thread is ready to run ?
Each thread has a time burst, I asked if the thread has to run its full time burst for e.g. 6 is th0 time burst, so the timer should fire an IRQ after 6 ticks. Or, the timer fires IRQ after each tick and I should check if there is a higher priority thread than the current one, if it is then I should stop the current one from running and run the higher priority one. And the current one would have not completed its time burst.
Either.
So, a thread will be pre-empted if:
- It has run it's time full time burst.
- It has not yet run its full time burst. But in the mean time, another, higher priority thread has become runnable.
The latter can be in response to any event, not just ticks. A UI thread might be waiting for user input, for example, and a mouse or keyboard event causes an interrupt. The kernel will service the interrupt, which queues an event for the UI thread, which is then woken up possibly at a higher priority than the current thread.
In fact, in this latter case, if your mouse/kbd is USB based, the interrupt will enable the USB thread, which will itself pre-empt the running process, and that USB thread will then trigger further events to wake up the UI thread.
Eventually, once the higher priority threads are done (interactive threads tend to do their stuff rather quickly,) the scheduler will get back to your pre-empted thread, and pick it up again.
Another difference between a thread using its full time burst and a thread that is pre-empted by higher priority thread is how the pre-empted thread is queued for future running.
In the case of a thread using its full time burst, it may be placed on the back of its priority queue, whereas a thread pre-empted by a higher priority thread may be placed onto the front of its priority queue, so it is picked up straight away to finish its time burst when the scheduler next gets to its priority.