How does the operating system distribute the processor across the various programs?

Question

In current operating systems there is possibility of having several programs running. It is the work of the operating system to ensure that all programs have opportunity to perform work (process code instructions).

Everything would be easier if there was a limit on the number of programs the operating system has running. For example, 1 program for each core processor. The limit on computers today would then be between 4 to 8 programs on computers for more modern consumers.

But the reality is that there is a much larger number of programs that I can have running. Not to mention that each program can have more than one thread, one thread always runs on a processor core (although it is possible to change core during execution, so I know).

How do these programs continue to work? Why don’t they crash? How the operating system distributes the processor between the various programs/threads?

Answer 1

Introducing

Almost always the operating systems allowed to work like this. Of course some do not, but do not need to have multiple processors, physical or logical, so that various processes or even threads can rotate "at the same time".

There is gain in doing this whenever there is waiting for some reason. Either because the hardware is manipulating data on its own, or because the application itself is on hold. So limiting the amount of execution lines would bring harm since nothing is being done during these breaks.

It would be easier but it would not be ideal. The difficulty was the price that decided to pay to better take advantage of the available resources. The idea is to keep the processor busy.

Adding more processors does not solve this. The reason is explained in It’s always guaranteed that a multi-threaded application runs faster than using a single thread?.

Scheduling

There is a scheduling system that is a specific algorithm of operating systems to go giving processor control to each existing processing line. The operating system lets a line run for a while and then there is an interruption that returns the processor control to the operating system which can then decide what to do with the processor.

This is done with specific processor instructions that creates interruption in execution after the time set by the operating system. The interruption is like an event that many know at a high level, only it is controlled by the hardware.

These algorithms begin with the creation of lists of execution lines that are requested through the process API of threads. According to the settings the operating system will allocate a processor for that line, being able to change it following some criteria, and a specific time (few microseconds) for it to run until it returns to the operating system. This time may vary according to the amount of existing lines.

The OS stays in a loop and when it gets control it delivers to another execution line. The frequency that a line is called can also be controlled some Sos, so it is not necessary for all existing lines to run once to run again.

All this depends on the implementation of each system and the conditions of the environment that is running.

Some use quite sophisticated algorithms to give the best possible result for each situation.

Think of him as a traffic cop or a smart traffic light. Well, technically a basic traffic light is a pretty good analogy, except Sos are usually better than this.

This is the preemptive multitasking. In the past some Sos use cooperative multitasking. There was no interruption, so the OR relied on the application’s willingness to return control to it. This would lock in if the application "screws up". With the hardware helping and the OS using the preemption the application cannot take over the processor. Interrupt configuration instruction is only accessible by the OS.

There are real-time operating systems that need to give more guarantees on execution.

Obviously this is a summary for laypeople.

Wikipedia article on the subject.