Sorry your browser is not supported!

Hello, yep, it's another Geek Culture question about how os's do things I was reading about multitasking, and how the computer uses context switches to switch to another task. But how does the computer know when to context switch if the process responsible for doing that isn't the one being processed? My guess is that context switching is done at the hardware level?? Im confuzzled Thanks for unconfuzzling me!

Computers have several devices built in that can cause signals to be sent to the processor for special processing - one of these is a timer that can be set to trigger an event when a certain amount of time has passed.

There are several ways for computers to deal with these events, one of which is called an interrupt. An interrupt basically causes the processor to jump to a certain piece of code when an event occurs.

On the PC there are many different interrupt types, and each can be handled by a different piece of code, the addresses of which are held in a table - when the processor receives an interrupt for the timer event, it selects the timer interrupt address from the table, and jumps to that piece of code to execute it.

That code will save the current context, which includes, but is not limited to, the old instruction pointer (before the jump), the stack pointer, the general purpose registers, the floating point registers, the segment registers and the flag register.

It will then determine which process should be the next to get some processing done, and will restore the context for that process, ending by jumping to the instruction saved for that context.

Between saving one context and restoring the next, the OS gets its chance to do a little housekeeping, and in addition, the context it restores may actually be one of it's own if a larger amount of processing needs to take place.

Also, it isn't just the timer that can cause these kinds of interrupts - there are all sorts of events that may need to be dealt with, such as network traffic, keyboard/mouse activity, data received from the hard-drive from a previous data fetch etc.

Thanks! So the hardware is responsible for telling the cpu when to do a context switch?

Yes, but remember that it's the software that sets up the timer interrupts in the first place.

Also, this is for a single core. With multiple cores, multiple threads actually do run at the same time. Each core has its own context and interrupt handler so each can switch between threads independently.

One of the complexities of a multi-core OS is synchronising the cores. If you have threads A, B and C in a processor with two cores, the first core could be running A, the second running B. Then a timer interrupt fires and they check which threads are not already being run. They might each see that C is not running, and then both try to run it at the same time, which would obviously cause problems.

To solve this you need some way to synchronise the cores. However if you keep needing to wait for the other core to be ready, then you lose much of the benefit of having multiple cores. Finding efficient ways to do this can greatly affect the performance of an OS.

I see, thanks! Ok, just to get this straight, the software tells the computer hardware when to do a timer interrupt??? I dont know why this is so confusing to me!! lol... The only other way i can think is that the exe code is going through the kernel so the kernel is still able to know when to move to the next process.

The timer runs independently of the code currently running.

It's quite simple really. The timer will start at some value - however long it's going to give to a process, and it will decrement completely independently of the rest of the processing. It's done in hardware. When it reaches 0, it will reset it's value and send an interrupt to the CPU. The CPU will then save it's context and then switch to another process.

THANK YOU! That simplifies everything!