Systemnahe Informatik

Wenn du einen Webserver (wie Nginx) schreibst. Du musst wissen, wie TCP/IP Pakete aussehen. Du musst "File Descriptors" verwalten. Du nutzt System Calls (fork, exec, mmap), um mit dem OS zu reden. Oder wenn du Game Engines schreibst (Grafikkarten ansteuern).

1. Memory Management

Das Herzstück. Im User Space hast du malloc und free. Im Kernel musst du den virtuellen Speicher verwalten (Paging). Du musst wissen, was ein TLB (Translation Lookaside Buffer) ist und warum ein Cache Miss 100x langsamer ist als ein Register-Zugriff.

2. Concurrency

Keine "Promises". Echte Threads, Mutexes, Spinlocks, Atomics. Du musst Race Conditions auf Hardware-Ebene verstehen ("Memory Barriers").

1. Kernel-User Boundary & Syscall Overhead

Jeder Wechsel vom User- in den Kernel-Mode (z.B. um eine Datei zu lesen) ist teuer. Die CPU muss den "Context" wechseln (Register sichern, Page Tables umschalten oder flashen). Experten nutzen daher Techniken wie Batching (viele Anfragen auf einmal) oder io_uring (ein moderner Linux-Mechanismus, der eine Ring-Buffer-Queue nutzt). Damit können User-Apps und der Kernel kommunizieren, ohne dass die CPU ständig teure "Context Switches" machen muss. In Hochleistungs-Systemen (Webserver für Millionen User) entscheidet das über Sieg oder Niederlage.

2. Interrupt Handling (Top-Half / Bottom-Half)

Wenn die Netzwerkkarte schreit: "Daten da!", schickt sie einen Interupt. Die CPU stoppt alles. Aber: Wenn die CPU zu lange im Interrupt-Handler bleibt, verpasst sie andere wichtige Dinge. Lösung:

• Top-Half: Extrem kurzer Code, der nur sagt: "Ok, ich hab's gemerkt", die Daten kurz sichert und den Interrupt quittiert.
• Bottom-Half (Softirqs/Tasklets): Die eigentliche Arbeit (Paket verarbeiten, Prüfsummen rechnen) wird in eine Queue geschoben und erst gemacht, wenn die CPU wieder "Luft" hat. Das ist die hohe Schule des Kernel-Designs.

3. DMA & Cache Coherency

Systemnahe Programmierung nutzt oft DMA (Direct Memory Access). Hardware schreibt direkt in den RAM. Aber Vorsicht: Die CPU merkt das nicht! Wenn die CPU einen Wert im Cache hat und die Hardware den Wert im RAM ändert, sieht die CPU den alten Wert (Stale Data). In der Produktion muss der Informatiker den Cache explizit "invalidieren" oder "flashen" (Cache Barriers), bevor er auf Daten zugreift, die gerade von der Hardware (z.B. SSD oder Netzwerk) kamen. Ein Fehler hier führt zu den gefürchteten "Heisenbugs", die nur alle 3 Wochen auftreten.

Vertiefung im Glossar

Für Netzwerk- und Kernel-nahe Systeme lohnt sich danach ein Blick auf XDP (eXpress Data Path), Tetragon, RDMA (Remote Direct Memory Access), QUIC, Multipath TCP (MPTCP), VPC Flow Logging und UEBA (User and Entity Behavior Analytics). Wer WebAssembly systemnah betrachtet, findet Anschlussbegriffe in Threads in Wasm, SIMD in Wasm (Fixed-Width SIMD) und WebAssembly GC (Garbage Collection). Für CPU- und Speichergrenzen sind Speculative Execution, Out-of-Order Execution (OoO), Sequential Consistency, Linearizability und Litmus Test (Concurrency) die nächsten Vertiefungen.