Correct me if I'm wrong, but if I have an operating system that makes a context switch, then that context switch is in practice a switch from one thread to another, where one thread was running one task and then switches to another task and the reason the threads needs a stack is to save the variables of the task to be able to return to its saved state.

Is my understanding correct of what a context switch does or did I misunderstand?

  • Seems reasonable to me. Why are you not sure? – Robert Harvey Jun 15 '16 at 0:09
  • @RobertHarvey I saw the stacks in the code for a project that uses MicroC from Micrium, and I wondered why the stacks were needed. Maybe I can read more about context switch in Tanenbaum's book about operating systems. I want to be able to implement a context switch myself, then only recently I realized that a context switch is more or less the same as switching between threads. – Niklas Jun 15 '16 at 0:29

The stack has nothing to do with multi-threading. The stack saves information about a subroutine. When I say sub-routine, I am not speaking about any particular language, but the process of making a call to another area of the program space, and returning from that area when finished. When making the call, the currently executing routine may be using registers. Those register values must be saved in a stack, so that the called routine can use those registers. This is greatly simplified, but the general idea is the stack saves the context of the caller, and the stack grows larger as the call chain grows deeper.

If you have multiple threads, each one needs a stack, since they are all executing at the same time. The context switch allows you to have more threads than CPU cores. It allows multiple threads to share one core by pre-empting the execution of a thread, and starting another thread.


You're mostly on the right track. The stack's purpose in general is to hang onto data you'll need later. Most of the time, that's done when calling subroutines, at the very least to save the return address, but also to save any state that may be destroyed otherwise and as a mechanism to store local variables and to pass parameters. In most multitasking systems, every execution context has its own stack for those purposes.

Many systems also use the context's stack when switching between them.

When a context stops executing, everything it had going on needs to be preserved. The stack will already hold most of that, but the state of the processor's registers has to be collected and stored as well.

This information could be stored in a data structure allocated specifically to do that job, maybe as part of a process control block. The thing about that approach is that you'd need one per context, and the structures would be occupying space unnecessarily while the context is running.

As it happens, there's already a block of general-purpose scratchpad memory available: the stack. Once control has been wrested from the context, there is zero chance that it will be pushing anything else there. This makes it safe for the supervisor to push the processor state there, and all it has to remember for later is the context's stack pointer. Because the context won't run until the supervisor gives it the okay, the last things pushed to the stack will always have been the processor state. When the context is to be restarted, the supervisor restores the saved stack pointer, pops the remainder of the processor state from the stack, jumps to the address where the program counter was when the context was interrupted (also stored on the stack). Then the context continues running as if nothing had happened.

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.