8
\$\begingroup\$

I'm an embedded developer. I haven't worked with RTOS/linux. I was going through RTOS concepts when I stumbled upon 'context switching'. I understand that when context switch occurs, all the registers along with PC(Program Counter) gets saved in stack before another thread is loaded to the processor. Isn't a similar thing happening when an interrupt occurs(in a controller which doesn't use any kind of OS)?

How different are those two terms?

\$\endgroup\$
4
  • 1
    \$\begingroup\$ AFAIK, on most microcontrollers the context saving when an interrupt occurs happens in hardware while the context saving in an RTOS happens in software \$\endgroup\$
    – m.Alin
    Nov 10, 2014 at 11:41
  • \$\begingroup\$ An interrupt handler may not need to save all the thread state (having relatively little work to do). Some ISAs provide shadow/banked (MIPS/ARM) registers to avoid save/restore overhead or automatically save a limited amount of state (which is comparable to having such as shadow/banked registers). (Incidentally, MIPS MultiThreading Application Specific Extension extends Shadow Register Sets (31 GPRs) into Thread Contexts.) [Too short for an answer, but a quick response.] \$\endgroup\$ Nov 10, 2014 at 12:13
  • \$\begingroup\$ each context usually has it's own stack allocated, so it's faster to switch to them than having to save all the register values onto the stack before switching and them pop them off after. The interrupt handlers in a microcontroller often have to do this manually in code, but if you use a RTOS on the microcontroller such as uCOS-II/III by Jean C Labrosse, each task/context has it's own stack and 'context' \$\endgroup\$
    – KyranF
    Nov 10, 2014 at 12:25
  • \$\begingroup\$ @PaulA.Clayton can you elaborate your answer, i have no idea of how a thread runs only just a top level understanding. thanks though \$\endgroup\$ Nov 15, 2014 at 13:00

2 Answers 2

2
\$\begingroup\$

There isn't a fundamental difference, it's more a question of degree — the amount of context that needs to be saved.

When an RTOS thread context switch occurs, all of the CPU state that any thread might use must be saved. This usually includes all of the CPU registers, including flag or status registers, so that when they're restored, the thread resumes as though nothing ever happened.

When an interrupt occurs, there's still a context switch, but only the context that the interrupt handler actually needs to use needs to be saved and then subsequently restored. If you write your interrupt handler in a high-level language, this will pretty much be equivalent to a full thread context switch, because there are no constraints on what resources such an interrupt handler might touch. However, if you write your interrupt handler in assembly language, you can keep track of exactly which registers it touches and save only those. This allows the execution of the interrupt handler to be extremely fast, reducing its impact on the rest of the system, and/or allowing it to handle interrupts at a higher rate.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Even when an interrupt handler is written in a high-level language, if the handler doesn't call any outside code the compiler doesn't "know about", the compiler may be able to generate register save/restore code that ignores registers that aren't used by the interrupt handler itself. Since the very nature of a "full" context switch is to allow the execution of arbitrary code, it must save/restore all registers whether or not the compiler is aware of anything that actually uses them. \$\endgroup\$
    – supercat
    Nov 10, 2014 at 17:36
2
\$\begingroup\$

Both interrupts and context switches are interrupts. The main difference is in what happens after the interrupt or context switch.

With an interrupt the current state (or context) is stored in a temporary area (usually, but not always, the stack). The ISR then does its thing, and the state is then restored and the interrupt routine returns. The crucial thing here is that the ISR returns exactly where it left off in the same thread.

A context switch looks just like an interrupt. The state is stored in the stack as per usual. However, the location of that stack and any extra state information is stored elsewhere (in the thread). A new set of data from another thread is then substituted with the current data and the ISR returns. Here though the ISR doesn't return to where it left off, but it returns to where the newly switched in thread was interrupted the last time a context switch occurred while it was running.

It's this change of return location and data that, besides what the content of the ISR may be, distinguishes an ISR form a context switch.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.