Operating systems: the manager between apps and hardware

Explore the software that gives programs a usable environment—scheduling work, organizing memory and files, connecting devices, and enforcing boundaries.

What an operating system does

An operating system (OS) is the software that manages a computer's resources and provides common services to applications. It lets programs work with files, memory, displays, networks, and other devices without each program needing to control every hardware detail directly.

When several programs are open, the OS decides how they share processor time and memory. When an application reads a file, the OS checks access, locates the data, and coordinates with storage hardware. When a device reports input, the OS routes that event to the relevant program.

• Resource management: share CPU time, memory, storage, and devices.
• Abstraction: provide stable interfaces over different hardware.
• Protection: isolate programs and control access to data and devices.
• Convenience: provide services such as files, networking, and user interfaces.

Desktop, mobile, server, and embedded operating systems have different priorities, but they solve many of the same core problems.

User space, the kernel, and system calls

The kernel is the privileged core of an operating system. It manages low-level resources and responds to requests from programs. Most applications run in user space, where hardware access is restricted. This separation limits the damage a faulty or untrusted application can cause.

A system call is a controlled request for a kernel service, such as opening a file or creating a process. Libraries often provide friendlier functions that eventually make system calls. A typical file read follows this general path:

1. The application asks a library to read bytes from a file.
2. The library requests the OS file service.
3. The kernel checks access and requests data from storage if needed.
4. The OS reports bytes read or an error to the application.

System calls cross a protection boundary, so they have more overhead than an ordinary function call. Programs usually use libraries and buffers to make repeated operations efficient.

Processes and threads

A process is a running program together with its execution state and resources. A process typically has a protected virtual address space, open files, security credentials, and one or more threads. An executable file is not itself a process; it becomes one when the OS loads and starts it.

A thread is an execution path within a process. Threads in the same process commonly share memory and open resources, but each has its own execution state such as the current instruction and call stack. Sharing makes communication convenient, yet unsynchronized updates to common data can cause race conditions.

Concept	What it represents	Typical relationship
Program	Stored instructions and related files	Can be launched to create a process
Process	Running instance with resources and an address space	Contains one or more threads
Thread	Path of execution scheduled by the OS	Threads in a process can share its memory
Context switch	Save one execution state and resume another	Enables the CPU to alternate among tasks

Processes often communicate through explicit mechanisms such as pipes, sockets, shared memory, or message queues. Separate processes provide stronger isolation; threads can share data more directly but require careful coordination.

A process changes state over time

A process is often described as new, ready, running, waiting, or terminated. A ready process can run as soon as the scheduler selects it. A running process may move to waiting when it requests input or storage, then return to ready after that event completes. A process terminates when its work ends or it is stopped.

These states help explain why a process can appear inactive without being broken. A program waiting for a network response is not using much CPU, while a process continuously computing may remain runnable. Operating systems expose state and resource information through monitoring tools, though exact labels vary by platform.

Starting a program

To start a program, the OS creates process state, establishes an address space and security context, loads program code and required data, prepares a thread, and schedules it. When a process exits, its exit status can be collected by the program that launched it. Child processes can help applications divide work, but creating too many processes consumes memory and scheduling time.

Scheduling and concurrency

The scheduler chooses which ready thread or process should use a processor. On a single CPU core, the OS can rapidly switch among tasks, creating the impression of simultaneous progress. On a multicore processor, multiple threads can actually execute at once.

Scheduling policies balance goals such as fairness, responsiveness, throughput, and deadlines. A desktop may prioritize interactive response; a batch system may aim to finish many jobs efficiently. There is no single policy that is best for every workload.

Concurrency needs coordination

Concurrency means multiple tasks make progress during overlapping periods; parallelism means tasks run at the same time on separate execution units. Shared state introduces hazards: two operations may interleave in an unexpected order, or one thread may observe a partially updated value.

shared_count = 0

Thread A: read shared_count   // sees 0
Thread B: read shared_count   // sees 0
Thread A: write 1
Thread B: write 1

// Two increments occurred, but the result is 1.

A mutex allows only one thread at a time into a protected region. Other tools include semaphores, condition variables, atomic operations, and message passing. Correct synchronization avoids races while also avoiding deadlocks, where tasks wait indefinitely for resources held by one another.

Scheduling policies make trade-offs

A simple first-come, first-served policy is easy to understand, but one long task can delay many short interactive tasks. A time-slicing policy gives each runnable task a short turn, then switches to another task if the current one has not finished. A real operating system uses more sophisticated priorities and heuristics, but the example shows why scheduling policy affects response time as well as total work completed.

Priority scheduling can keep important work responsive, but a low-priority task may wait too long if higher-priority work continually arrives. Systems use techniques such as priority adjustments to reduce this risk. Real-time systems have different goals: they may need to meet timing deadlines, not simply maximize average throughput.

How deadlocks happen

A deadlock occurs when tasks wait forever for resources that cannot be released. Imagine thread A holds lock 1 and waits for lock 2, while thread B holds lock 2 and waits for lock 1. Neither can proceed. Using a consistent lock order, keeping protected regions small, and avoiding unnecessary shared locks can reduce deadlock risk. Some systems detect or recover from deadlocks; many application-level deadlocks must be prevented through design.

Synchronization is not only about adding locks. A lock must protect every access to the shared state it governs, and threads must agree on how locks are acquired. Too much locking can reduce parallelism; holding a lock while waiting for slow input can block unrelated work.

Memory and virtual address spaces

Each process generally sees a virtual address space: an address range that appears private and continuous. The OS and memory-management hardware translate virtual addresses to physical RAM and enforce access rules. This abstraction allows the OS to isolate processes and move or share physical pages as needed.

Virtual memory does not mean every byte is always in RAM. The OS may load pages when they are first accessed, share read-only pages between processes, or move inactive pages to storage under memory pressure. Accessing a page that is not currently resident can cause a page fault; some page faults are normal and handled transparently, while invalid access can terminate a program.

Allocation and memory pressure

Programs request memory through language runtimes or OS interfaces. Memory can be automatic, dynamically allocated, or managed by a garbage collector, depending on the language. Leaks, excessive allocation, and fragmentation can reduce available memory or slow an application.

When physical memory is scarce, the system may reclaim caches or move pages, but severe pressure can make the computer sluggish. More memory is not always the solution: a program may also need to release unused objects, stream large files, or avoid holding duplicate data.

What a page fault tells the system

Memory is managed in fixed-size units called pages. When a program accesses an address whose page is not currently mapped for it, the hardware raises a page-fault event. The OS checks whether the access is valid. It may map an existing page, load contents from storage, create a zero-filled page, or report an invalid access to the program.

A page fault is not automatically a bug. Programs commonly trigger faults as memory is first used. However, frequent faults that require storage access can be expensive and may indicate that the active working set is too large for available RAM. Understanding this distinction helps interpret performance tools accurately.

Files, directories, and persistent storage

A file system organizes data on storage devices into named files and directories. It tracks data locations and metadata such as file size, ownership, permissions, and timestamps. Applications use file paths and OS interfaces rather than addressing disk sectors directly.

Reading or writing a file can involve caches and buffers. A successful write reported by an application does not always mean every byte has already been committed to physical media. Applications that require durability must use the guarantees and synchronization operations provided by their OS and storage stack.

Paths and permissions

A path identifies a file within a directory hierarchy. Absolute paths begin from a file-system root; relative paths begin from a program's current working directory. File permissions and ownership rules help determine which users and processes may read, modify, or execute a file.

File names are not a security boundary. Programs should validate paths and use platform-supported APIs for temporary files, permissions, and safe file handling rather than assuming input paths are harmless.

File descriptors and open handles

After opening a file, an application usually works through a small handle or descriptor rather than repeating the full path for every read. The OS tracks the open resource and the program's permissions. Closing the handle releases associated resources. Programs should close files reliably, often with language features that guarantee cleanup even when an error occurs.

Files can also be represented as streams. A stream lets a program process data incrementally instead of loading an entire large file into memory. This is useful for logs, media, and data-processing tasks where only a portion needs to be held at once.

Devices and input/output

Keyboards, disks, displays, cameras, and network adapters differ in how they operate. A device driver translates operating-system requests into device-specific commands and reports results back. The OS offers more consistent interfaces so applications can work across multiple devices.

Input/output may be blocking or asynchronous. A blocking call waits until the operation completes; asynchronous interfaces let a program continue other work and receive a completion event later. Buffering and batching reduce the overhead of many small device operations.

Device events may arrive independently of the program's current activity. Operating systems coordinate these events using interrupts, queues, and event-delivery mechanisms. Drivers are trusted components because they operate close to hardware and often have elevated privileges.

Protection, accounts, and permissions

Operating systems use accounts, permissions, process isolation, and access-control mechanisms to limit who can use resources. The principle of least privilege says a program or account should receive only the access needed for its job, and only for as long as it needs it.

Authentication establishes which account is acting; authorization decides what that account may do. They are related but different. A program running with broad administrative privileges can cause greater harm if it contains a defect, so ordinary work should generally use ordinary permissions.

Isolation is not absolute protection against every attack or failure. Keep operating systems and software maintained, use trusted sources, protect credentials, and treat unexpected permission prompts carefully.

Observe and troubleshoot a system

When a computer slows down or a program fails, separate the symptom from its cause. Is CPU time high, memory exhausted, storage busy, or a network request waiting? System monitors, process listings, logs, and application diagnostics provide evidence for these questions.

1. Record what the user sees and when it occurs.
2. Check whether the issue affects one process or the whole system.
3. Inspect resource use and relevant logs without exposing private data.
4. Try a small reproducible case and change one variable at a time.
5. Confirm that a fix addresses the cause and does not create a new issue.

A process that uses a lot of CPU may be doing expected work, stuck in a loop, or repeatedly retrying a failed operation. Measurement narrows the possibilities; it does not replace understanding the program's behavior.

Compact glossary

Kernel

The privileged core of an operating system that manages hardware resources.

System call

A controlled request from a program for an operating-system service.

Process

A running program with managed state and resources.

Thread

An execution path within a process.

Race condition

A result that depends on the timing or interleaving of concurrent operations.

Virtual memory

An address-space abstraction managed by the OS and hardware.

References and further reading

1. Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau. Operating Systems: Three Easy Pieces. Free online book.
2. Abraham Silberschatz, Peter B. Galvin, and Greg Gagne. Operating System Concepts, 10th edition. Wiley, 2018. Author resources.
3. Linux man-pages project. Linux system call and library documentation. Reference site.

Try it yourself

1. Draw a diagram showing how an application asks the OS to read a file.
2. Explain the difference between a program, a process, and a thread.
3. Trace the lost-update example above. What synchronization would prevent it?
4. Why does virtual memory help isolate processes?
5. Choose an everyday slowdown and list what evidence could distinguish CPU, memory, disk, and network bottlenecks.

Remember: the OS coordinates shared resources and provides safe, consistent services between applications and hardware.