Systems Programming

Systems programming is programming where the machine's physical constraints -- memory, concurrency, I/O bandwidth, latency -- are not abstractions but design parameters. A web application can ignore cache lines; an operating system kernel cannot. This skill catalogs the concepts that distinguish systems programming from application programming, with emphasis on the mental models needed to reason about programs that interact directly with hardware and operating system primitives.

Agent affinity: hopper (compilers, language implementation, systems), turing (computability, machine models)

Concept IDs: code-abstraction, code-code-organization, code-debugging-strategies

Part 1 -- Memory Management

Stack vs Heap

Stack. LIFO allocation. Each function call pushes a frame; return pops it. Allocation and deallocation are free (pointer arithmetic). Size is bounded (typically 1-8 MB per thread). Perfect for local variables with known lifetimes.

Heap. Dynamic allocation. Memory is requested explicitly (malloc/new/Box::new) and freed explicitly or by a garbage collector. Slower than stack (allocator must find free space, manage fragmentation). Necessary for data whose size or lifetime is not known at compile time.

The fundamental tradeoff. Stack allocation is fast but inflexible (fixed size, LIFO lifetime). Heap allocation is flexible but slow (allocation overhead, fragmentation, potential leaks).

Manual Memory Management (C)

malloc/free. The programmer requests memory and is responsible for returning it. Every malloc must have a corresponding free. Failure modes:

• Memory leak: malloc without free. Memory grows until the process is killed.
• Use-after-free: Accessing memory that has been freed. Undefined behavior -- the memory may have been reused.
• Double free: Freeing memory twice. Corrupts the allocator's data structures.
• Buffer overflow: Writing beyond allocated bounds. The most exploited vulnerability class in computing history.

Garbage Collection

Mark-and-sweep. Starting from root references (stack, globals), mark all reachable objects. Sweep (free) unmarked objects. Simple but causes pause times proportional to heap size.

Generational GC. Observation: most objects die young. Divide the heap into generations (young, old). Collect the young generation frequently (fast, small) and the old generation rarely (slow, large). Used by JVM, .NET, V8.

Reference counting. Track the number of references to each object. Free when count reaches zero. Immediate reclamation but cannot collect cycles (A references B, B references A, nobody else references either). Python uses reference counting plus a cycle detector.

Tradeoffs. GC eliminates use-after-free and double-free. It introduces unpredictable pause times and higher memory usage (objects may survive longer than necessary). Real-time systems and game engines often avoid GC.

Ownership and Borrowing (Rust)

Rust's ownership system eliminates both manual memory bugs and GC overhead:

• Ownership: Every value has exactly one owner. When the owner goes out of scope, the value is dropped (freed).
• Move semantics: Assigning a value to a new variable moves ownership. The old variable is no longer valid.
• Borrowing: References (&T for shared, &mut T for exclusive) allow temporary access without taking ownership. The borrow checker enforces at compile time: either one &mut or any number of & at any given time.
• Lifetimes: Annotations that tell the compiler how long a reference is valid. Prevents dangling references at compile time.

This system achieves memory safety without runtime cost. The price is compile-time complexity -- the borrow checker rejects programs that are correct but cannot be proven safe by its rules.

Part 2 -- Concurrency

Threads

A thread is an independent sequence of execution within a process. Threads share the process's address space (heap, globals, file descriptors) but have independent stacks and program counters.

Creating threads. POSIX pthreads (C), std::thread (C++/Rust), threading module (Python), Web Workers (JavaScript, no shared memory).

The problem. Shared mutable state + concurrent access = data races. A data race occurs when two threads access the same memory location, at least one writes, and there is no synchronization between them. The result is undefined behavior.

Synchronization Primitives

Mutex (mutual exclusion). A lock that ensures only one thread can access a critical section at a time. Lock before accessing shared state, unlock after. Deadlock occurs when two threads each hold a lock the other needs.

Read-write lock. Multiple readers OR one writer. Better throughput than mutex when reads dominate.

Condition variable. Allows a thread to sleep until a condition is signaled by another thread. Used with a mutex to avoid busy-waiting.

Semaphore. A counter that controls access to a finite pool of resources. P (wait/decrement) and V (signal/increment). Mutex is a semaphore with count 1.

Atomic operations. Lock-free read-modify-write operations (compare-and-swap, fetch-and-add). Used for counters, flags, and lock-free data structures. Require understanding of memory ordering (relaxed, acquire, release, sequentially consistent).

Channels (Message Passing)

Instead of sharing state, threads communicate by sending messages through channels. The sender puts a message in; the receiver takes it out. No shared mutable state, no data races.

Go's philosophy: "Do not communicate by sharing memory; share memory by communicating." Channels are first-class in Go, Rust, and Erlang.

Bounded vs unbounded. A bounded channel blocks the sender when full (backpressure). An unbounded channel never blocks but can consume unlimited memory.

Async/Await

Problem. Threads are expensive (1 MB stack each, OS scheduling overhead). A web server handling 10,000 concurrent connections cannot afford 10,000 threads.

Solution. Cooperative multitasking. An async function yields control when it waits for I/O. A runtime (event loop, executor) multiplexes many async tasks onto a small number of threads.

Mental model. Async code looks sequential but executes concurrently. Each await is a potential suspension point. The task resumes when the awaited operation completes.

Languages. JavaScript (single-threaded event loop), Python (asyncio), Rust (tokio, async-std), C# (Task-based).

The Actor Model

Principle. Each actor is an independent entity with its own state and mailbox. Actors communicate exclusively by sending messages. No shared state, no locks.

Implementations. Erlang/OTP (the original), Akka (JVM), Actix (Rust).

When to use. Distributed systems, fault-tolerant systems, systems with many independent entities (IoT, game servers, telecom switches). Erlang's "let it crash" philosophy -- actors fail independently and are restarted by supervisors.

Data Race vs Race Condition

Data race: Two threads access the same memory, at least one writes, no synchronization. Undefined behavior. Prevented by Rust's type system, thread sanitizers (TSan), or correct use of synchronization.

Race condition: The program's correctness depends on the timing of operations, even if each individual access is synchronized. Example: check-then-act (if file exists, then open file -- another process may delete it between check and act). Harder to detect and fix.

Part 3 -- Operating System Concepts

Processes and Virtual Memory

A process is an instance of a running program. Each process has its own virtual address space -- an illusion that it has the entire memory to itself. The OS and hardware (MMU) translate virtual addresses to physical addresses via page tables.

Page fault. When a process accesses a virtual page that is not in physical memory, the OS loads it from disk (swap) or alloc