0

I have a question about IA32 tasks.

A TSS allows only one context to be saved for a task; therefore, once a task is called(dispatched), a recursive (or re-entrant) call to the task would cause the current state of the task to be lost.

I simply don't understand why tasks are non-reentrant in IA 32. If you have a task running and then you do a jmp far using the tss segment selector of the actual task, the current state of the task will be saved in the tss. Then it will search for the tss descriptor, and load the state that has been previously saved. So, the EIP woulb point to the next instruction,etc. What is wrong with this reasoning?

I understand how the busy bit works, but not the reason why they forbid calling the same task. I notice that if you have a chain of nested task, and then one calls itself, it will create a sort of loop because the previous task link of the tss will be itself.

Nem Esis
  • 1
  • 2
  • I don't know a lot about x86 task-switches, other than the fact that modern OSes don't use it because it's faster to do it in software. Presumably the design intent was for OSes to only use the "task" functionality to handle context-switches between user-space processes/threads. Is it even useful or sane for tasks to jump directly to other tasks (rather than having the OS's scheduler pick a task and jump to it)? Would it make sense in a microkernel, as a way of handing control to another kernel thread? – Peter Cordes Feb 13 '16 at 21:32
  • State isn't just about the `EIP`; you've got all the other registers, I/O port privileges, other privilege level stack pointers. Reentrancy implies that you can come back. If you've just destroyed the previous state of the task and then make significant modifications, what do you expect is going to happen when you try to come back? As for the 'why', that's a question for the hardware designers. – Anya Shenanigans Feb 14 '16 at 12:22

0 Answers0