If a thread is performing a blocking operation, typically waiting on a mailbox_receive() or similar, it calls dispatch_next() which yields the remainder of the timeslice to another thread.
However, this means that the other thread will not receive a full timeslice (which is normally 1000/32=~31 ms since we program the PIT to 32 Hz). It could be worthwhile to reprogram the PIT every time dispatch_next() is being called, so that each thread gets a fair share of CPU time when needed.
This does have a disadvantage though; we can no longer rely on the PIT interrupts to keep track of wall clock time and system uptime, since we will deliberately make some timeslices longer in these cases. So, if we go this route, we must make sure to adjust these measurements accordingly.
If a thread is performing a blocking operation, typically waiting on a
mailbox_receive()or similar, it callsdispatch_next()which yields the remainder of the timeslice to another thread.However, this means that the other thread will not receive a full timeslice (which is normally 1000/32=~31 ms since we program the PIT to 32 Hz). It could be worthwhile to reprogram the PIT every time
dispatch_next()is being called, so that each thread gets a fair share of CPU time when needed.This does have a disadvantage though; we can no longer rely on the PIT interrupts to keep track of wall clock time and system uptime, since we will deliberately make some timeslices longer in these cases. So, if we go this route, we must make sure to adjust these measurements accordingly.
/cc @doverhill