systems-programming

# 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