Click here to Skip to main content
14,237,722 members
Rate this:
Please Sign up or sign in to vote.
See more: (untagged)
I have the following doubt, whenever a task switch happens due to some system call, scheduler will store the cpu registers in its(say task A's TCB)(Task control block) and restore the cpu registers for the other task(task B) which is goiong to run from it own TCB.

My doubt here is, what happens during interrupt, where the cpu registers for the interrupted task is stored. My understanding is that it is stored in Interrupt stack(IRQ stack, let's take ARM). So if the registers are stored in IRQ stack, and if the interrupt results in the scheduler to switch to new task(my assumtion is that scheduler runs in timer interrupt context(system ticker)), how the scheduler store the interrupted task cpu registers, since it is stored in the IRQ stack. Only when the interrupt handler returns, then only the cpu registers are restore from the IRQ stack and interrupted task continue to execute. But if the interrupted results in scheduling of new tasks(say timer interrupt, which results in scheduler selects a new task), how the interrupt handler returns? how the old task resumes? How the old task registers are restored? I am bit confused . can anyone please help me to understand the above scenario?
Updated 23-Aug-15 8:47am

1 solution

Rate this:
Please Sign up or sign in to vote.

Solution 1

The interrupt behaves similarly to the call: the current address where the code was interrupted is stored on stack; the registers are pushed onto stack, and also the flags; it all is restored by the interrupt return instruction, so the execution continues at the point where it was interrupted.

This is what would happen in the single-thread system. With multiple thread, preemption happens on some interrupt, most typically, timer interrupt. From the standpoint of the interrupted task, the control is returned to interrupted point, as I explained in the previous character. System-wide picture can be more complex: the scheduler transfers control to some other thread, also at the point where it was interrupted before. So, for each thread it looks transparent: it always gets control at the point it was interrupted, but one or more other threads can take their time slices between the given interrupt and getting control.

It's not so easy to explain in simple words, but can be made clear if you draw the diagram and/or write some code, or pseuto-code. The low-level mechanism and CPU instructions involved is different in different processor architecture. Notably, it's very different for real-mode and protected mode of Intel x86* and IE-32/IE-64 architectures.


This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100