Operating and control systems

It sits between programs and hardware doing two jobs: abstraction — giving programs one standard way to ask for anything — and resource management, deciding who gets the CPU, memory and devices, and when.

Programs ask for what they need in one standard way whatever hardware is underneath. A program says 'save this file' without knowing which drive it is or how that drive works.

Because every program would then need to know every model of disk, printer and network card, and adding new hardware would mean rewriting all of them. With an OS, only a driver is added.

It gives each program its own region of memory, queues their requests for shared devices, and refuses direct access to hardware or to its own memory — programs have to ask.

A driver is added to the operating system, teaching it how to speak to that model. Every existing program keeps making the same standard request, so all of them work with it immediately.

Memory management, scheduling, file system, device management, security, accounting, graphical user interface, virtualization and networking — all running in the background at once.

Gives each program its own region of memory, tracks what is free, reclaims it when a program closes, and refuses any attempt to read or write memory belonging to another program.

Talks to every device through its driver and queues requests, so two programs never try to use one device at the same moment and no program needs to know the device's model.

Making one physical machine appear to be several separate ones, each running its own operating system and unable to reach the others. It is how a single server hosts many customers.

Each program has its own memory region and access outside it is refused; no program can address hardware directly. When one fails the OS stops it and reclaims its memory, leaving everything else running.

The rule the operating system uses to decide which process gets the CPU next, and for how long. A core runs one process at a time, so switching fast enough makes them appear simultaneous.

FCFS runs each process to completion in arrival order — simple, but one long job blocks everything behind it. Round robin gives each a fixed time slice then moves on, so everyone gets an early first turn, at the cost of time spent switching.

The highest-priority waiting process runs next, so urgent work always goes first — essential for real-time systems. The risk is starvation: a low-priority process may never run if urgent work keeps arriving.

Raising a process's priority the longer it has been waiting, so that even the lowest-priority work eventually reaches the front of the queue. It is the usual fix for starvation.

Processes are sorted into separate queues by what they are — interactive work in one, background batch work in another — and each queue gets its own scheduling rule and its own share of CPU time.

With polling the CPU repeatedly asks the device whether it is ready. With interrupts the device signals the CPU when it is ready, so the CPU can work uninterrupted until then.

The CPU finishes its current instruction, saves where it was, runs a short routine that deals with the device, then restores the saved state and carries on. That saving and restoring is the overhead.

When the device is almost always ready, so nearly every check succeeds and you avoid saving state thousands of times a second; and when a guaranteed response time is needed, since the delay is bounded by the checking interval.

Because the CPU can sleep between events, which uses very little power. Polling forces it awake to run checks that mostly find nothing, shortening battery life for no benefit.

Interrupts are raised by devices, so a faulty or malicious device can raise them constantly and leave the CPU no time for other work. Polling cannot be flooded, because the CPU decides when to look.