What are the reasons for the idle threads using TCB objects when the bookkeeping required for an idle thread is less than a user thread? On some architectures TCBs can be up to 2KiB in size.
I once experimented with making the idle thread a TCB like any other, and inserting it into the scheduler at low priority. Maybe that was the thought?
However, the idle thread itself is special, and we barely use any of the fields in the idle thread TCB (basically the state and it’s pointer). Users aren’t provided with a capability to the idle thread TCB so it cannot be invoked.
Changing this would require some changes to the proof to make the idle thread a minimal set of kernel state and not a TCB.
Yes, making the idle thread not have a TCB object would cause even more special cases for the idle thread in the proof. The more it can be handled like any other thread the better. The number of idle threads in the system is the number of CPUs. If that is large, we’d expect the overall memory size also to be large.
1 Like
I recall a former colleague saying that introducing the idle thread was great, because it simplified the interrupt etc exception handling paths. There’s always a TCB available with a register file into which the register state is saved the same way. Of course, this seems to create special cases for the idle thread everywhere else.
Doesn’t it scale with the number of domains as well? Or is that something that Qian’s work introduces?
Yeah, there’s an idle thread per domain per core.
We use idle threads as a work around for the scheduler and the IRQ handler.