Context switching and scheduling

Question

0.00/5 (No votes)

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?

Posted 23-Aug-15 8:45am

chandrAN2&

Updated 23-Aug-15 8:47am

v2

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Sergey Alexandrovich Kryukov · Answer 1 · 2015-08-23T18:20:00

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.

—SA