The Glossary of Operating System Concepts for Application Developers
Modern application developers rarely write code that talks directly to hardware, but every function call, network request, and file write still passes through the operating system underneath. Understanding these underlying concepts helps developers write faster, more reliable, and more secure applications — and makes debugging performance issues far less mysterious. This glossary walks through the core OS terms every application developer should recognize, grouped by theme.
Processes and Threads
Process A process is a running instance of a program. It has its own memory space, file handles, and execution context. When you launch an app, the OS creates a process for it, isolated from every other process on the system.
Thread A thread is the smallest unit of execution within a process. A single process can run multiple threads concurrently, and all threads in a process share the same memory space — which is efficient, but also the root cause of many concurrency bugs.
Multithreading Running multiple threads within one process to perform tasks in parallel (or to appear parallel on a single core). Useful for keeping a UI responsive while background work happens, but requires careful synchronization.
Context Switch The act of the CPU saving the state of one process or thread and loading the state of another. Frequent context switching (due to too many active threads) adds overhead and can hurt performance.
Process Scheduling The OS's method of deciding which process or thread runs next on the CPU. Schedulers balance fairness, responsiveness, and throughput using algorithms like round-robin, priority-based, or multilevel feedback queues.
Daemon / Background Process A process that runs in the background without direct user interaction, often handling tasks like logging, syncing, or listening for network requests.
Zombie Process A process that has finished executing but still has an entry in the process table because its parent hasn't yet read its exit status. Harmless in small numbers, but a sign of a bug if they accumulate.
Orphan Process A process whose parent has terminated before it did. The OS typically reassigns it to a special "reaper" process.
Memory Management
Virtual Memory An abstraction that gives each process the illusion of having its own large, contiguous block of memory, regardless of how physical RAM is actually laid out. This enables process isolation and lets the OS run more processes than would fit in physical RAM alone.
Physical Memory (RAM) The actual hardware memory installed in the machine. The OS maps virtual addresses used by applications to physical addresses behind the scenes.
Paging A memory management scheme that divides memory into fixed-size blocks called pages, allowing the OS to load only the parts of a program that are currently needed and swap out the rest.
Page Fault An event triggered when a program accesses a page that isn't currently loaded into physical memory, prompting the OS to fetch it — from disk, for example. Frequent page faults ("thrashing") signal memory pressure.
Heap The region of memory used for dynamic allocation — objects and data structures created at runtime with calls like malloc or new. Managed manually in some languages, automatically via garbage collection in others.
Stack The region of memory used for function calls, local variables, and control flow. Each thread has its own stack. Stack memory is allocated and freed automatically as functions are called and return.
Garbage Collection An automated process (used by languages like Java, Python, and Go) that reclaims heap memory no longer referenced by the program, reducing the risk of memory leaks but introducing its own performance considerations.
Memory Leak A situation where a program keeps allocating memory it no longer needs and never releases it, gradually consuming more RAM until performance degrades or the process crashes.
Segmentation Fault (Segfault) An error that occurs when a program tries to access memory it isn't permitted to touch — such as a null pointer or memory outside its allocated space. The OS terminates the offending process to protect the rest of the system.
The Kernel and System Interaction
Kernel The core of the operating system, responsible for managing hardware resources, memory, processes, and communication between software and hardware. It runs with the highest level of privilege on the system.
System Call (Syscall) The mechanism applications use to request services from the kernel — such as reading a file, allocating memory, or opening a network socket. Application developers usually interact with syscalls indirectly through library or language runtime functions.
User Space vs. Kernel Space Two separate memory regions: user space is where application code runs with restricted privileges, while kernel space is reserved for the OS core. This separation protects the system from misbehaving applications.
Shell A command-line interface that lets users and scripts interact with the OS by issuing commands, often used in build scripts, deployment pipelines, and automation tasks.
Driver Software that allows the OS (and by extension, applications) to communicate with a specific piece of hardware, such as a graphics card or network adapter.
Concurrency and Synchronization
Mutex (Mutual Exclusion Lock) A synchronization primitive that ensures only one thread can access a shared resource at a time, preventing race conditions.
Semaphore A more general synchronization primitive that controls access to a resource using a counter, often used to limit how many threads can use a resource simultaneously.
Race Condition A bug that occurs when the behavior of a program depends on the unpredictable timing or ordering of concurrent operations, often leading to inconsistent or incorrect results.
Deadlock A situation where two or more processes or threads are each waiting on a resource the other holds, resulting in neither making progress. Careful lock ordering and timeout strategies help prevent this.
Livelock Similar to deadlock, but the involved processes remain active and keep changing state in response to each other without making actual progress.
Atomic Operation An operation that completes entirely or not at all, with no possibility of being interrupted partway through — essential for safe concurrent programming without locks.
Inter-Process Communication (IPC)
IPC (Inter-Process Communication) A general term for the mechanisms that let separate processes exchange data, including pipes, message queues, shared memory, and sockets.
Pipe A one-way (or, with named pipes, sometimes bidirectional) channel that lets the output of one process feed directly into the input of another — the mechanism behind the | operator in shells.
Socket An endpoint for sending and receiving data across a network or between processes on the same machine, forming the basis of most networked application communication (HTTP, WebSockets, databases, etc.).
Shared Memory A region of memory that multiple processes can access directly, offering very fast IPC at the cost of requiring careful synchronization to avoid conflicts.
Signal A limited form of IPC where the OS notifies a process that a specific event has occurred, such as SIGTERM (a polite request to terminate) or SIGKILL (an immediate, forceful termination).
File Systems and I/O
File Descriptor A handle (usually a small integer) that a process uses to refer to an open file, socket, or other I/O resource. Running out of available file descriptors is a common cause of "too many open files" errors.
File System The structure the OS uses to organize, name, and store files on a storage device (examples include NTFS, ext4, and APFS).
Buffering Temporarily holding data in memory before writing it to disk or sending it over a network, reducing the number of slow I/O operations and improving throughput.
Blocking vs. Non-Blocking I/O Blocking I/O halts the calling thread until an operation completes; non-blocking I/O returns immediately and lets the program continue, checking back later — a distinction central to designing responsive, high-concurrency applications.
Asynchronous I/O A pattern where I/O operations are initiated and the program is notified (via a callback, event, or promise) when they complete, rather than waiting or polling — widely used in modern web servers and UI frameworks.
Scheduling, Performance, and Resource Limits
CPU-bound vs. I/O-bound A CPU-bound task spends most of its time doing computation, while an I/O-bound task spends most of its time waiting on external operations like disk or network access. This distinction shapes decisions about threading versus async design.
Throughput The amount of work a system completes in a given time period — useful for measuring overall system efficiency.
Latency The delay between a request and its response. Low latency matters most for interactive applications; high throughput matters most for batch processing.
Priority Inversion A scenario where a lower-priority task holds a resource needed by a higher-priority task, effectively causing the higher-priority task to wait — a subtle bug in real-time and multithreaded systems.
Resource Limits (Rlimits) OS-enforced caps on what a process can consume — such as maximum open files, memory, or CPU time — often configurable per process or user, and increasingly relevant when tuning containerized applications.
Virtualization and Containers
Virtual Machine (VM) A software-based emulation of an entire computer, including its own OS, running on top of a hypervisor. VMs provide strong isolation but carry more overhead than containers.
Container A lightweight, isolated environment that shares the host OS kernel while packaging an application with its dependencies. Containers (like Docker) start faster and use fewer resources than VMs, making them popular for deploying applications consistently across environments.
Hypervisor The software layer that creates and manages virtual machines, allocating physical hardware resources among them.
Namespace (Linux) A kernel feature that isolates system resources (like process IDs, network interfaces, or file systems) so that a group of processes sees its own isolated view of the system — a foundational building block for containers.
cgroups (Control Groups) A Linux kernel feature that limits and accounts for the resource usage (CPU, memory, I/O) of a group of processes, used alongside namespaces to implement containers.
Closing Thoughts
None of these concepts require an application developer to become an OS engineer, but even a working familiarity pays off constantly: reading a stack trace after a segfault, deciding whether a task needs a thread or an async callback, diagnosing why a container is being throttled, or understanding why a "simple" file write occasionally blocks the whole app. The operating system is the quiet foundation beneath every application — knowing its vocabulary makes that foundation far less opaque.
*written with Claude Sonnet 5
Reference