Im Jahr 1965 formalisierte Edsger Dijkstras Aufsatz Cooperating Sequential Processes das zentrale Problem des nebenläufigen Rechnens: was geschieht, wenn zwei oder mehr sequentielle Prozesse sich eine Ressource teilen. Sein Gedankenexperiment — die speisenden Philosophen, fünf an einem runden Tisch, jeder braucht beide angrenzenden Gabeln zum Essen — ist sechzig Jahre später noch immer die kanonische Veranschaulichung jener Fehlerfamilie, die Nebenläufigkeit hervorbringt: Deadlock, Aushungerung, Livelock, Race Conditions. Die tiefere Behauptung — entwickelt von Dijkstra, Tony Hoare und vor allem Leslie Lamport (dessen Time, Clocks, and the Ordering of Events in a Distributed System von 1978 zu den meistzitierten Aufsätzen des Fachs gehört) — lautet, dass nebenläufiges Programmieren qualitativ schwerer ist als sequentielles, weil seine Fehler sich nicht reproduzieren lassen, vom Timing abhängen und in der Produktion auftauchen, nachdem sie jeden Test überlebt haben.
Die fundamentale Schwierigkeit ist der Nichtdeterminismus: derselbe Code zweimal ausgeführt kann je nach Thread-Verschränkung verschiedene Ergebnisse liefern, und der Raum möglicher Verschränkungen wächst exponentiell mit der Zahl der Operationen — Tests können ihn im Allgemeinen nicht abdecken. Eine Race Condition — zwei Threads greifen auf gemeinsamen Zustand zu, das Ergebnis hängt davon ab, wer zuerst da war — ist der kanonische Fehler: das Hochzählen eines Zählers ist nicht atomar, denn lesen, plus 1, schreiben kann sich so verschränken, dass zwei nebenläufige Inkremente den Zähler nur um eins statt um zwei anheben. Moderne CPUs verschärfen das, indem sie Speicheroperationen aus Performance-Gründen umordnen — was ein Thread schreibt, wird einem anderen womöglich nicht in der geschriebenen Reihenfolge sichtbar; erst das Java-Speichermodell (2004) und das C++11-Speichermodell haben festgehalten, worauf sich Programmierer verlassen dürfen, davor war die Lage ein Sumpf. Die begriffliche Maschinerie zur Bändigung der Nebenläufigkeit läuft durch mehrere Traditionen: Locks schützen kritische Abschnitte, lassen sich aber schlecht zusammensetzen (zwei korrekte Komponenten können in der Kombination verklemmen); atomare Operationen wie Compare-and-Swap tragen lockfreie Algorithmen; und Nachrichtenaustausch-Modelle — Erlangs Actor-Modell, Gos Goroutines und Channels — ersetzen geteilten Speicher durch Kommunikation unter der Devise kommuniziere nicht, indem du Speicher teilst; teile Speicher, indem du kommunizierst. Zwei jüngere Ansätze haben die Landschaft verändert: CRDTs (konfliktfreie replizierte Datentypen) sind so entworfen, dass sich nebenläufige Aktualisierungen ohne Konflikt zusammenführen — das Fundament moderner kollaborativer Editierung in Google Docs, Notion und Figma; Rusts Borrow-Checker erzwingt zur Compile-Zeit, dass höchstens eine veränderbare Referenz pro Datenstück existiert, und beseitigt Datenrennen so durch Konstruktion. Verteilte Systeme dehnen die Nebenläufigkeit auf mehrere Maschinen aus und nehmen das Versagen mit hinein — verlorene Nachrichten, abgestürzte Knoten, partitionierte Netze. Das CAP-Theorem (Brewer 2000, von Gilbert und Lynch 2002 bewiesen) zeigt, dass man höchstens zwei von Konsistenz, Verfügbarkeit und Partitionstoleranz haben kann, und die FLP-Unmöglichkeit (Fischer-Lynch-Paterson 1985), dass in einem asynchronen System mit auch nur einem fehlerhaften Prozess Konsens unmöglich ist. Scharf und ernüchternd, ziehen diese Ergebnisse die Grenzen dessen, was verteilte Systeme leisten können.
Moderne Systeme sind standardmäßig nebenläufig — Laptops haben 8 bis 24 Kerne, Webserver bedienen Tausende gleichzeitiger Verbindungen, und jede größere Sprache bietet heute async/await-Zucker auf kooperativ geplante Aufgaben. Frameworks für verteilte Systeme (Kubernetes, Kafka, Spark) und Konsens-Protokolle (Paxos 1989, Raft 2013) tragen heute Systeme im Produktionsmaßstab; Bitcoins Proof-of-Work ist ein byzantinisch fehlertolerantes Konsens-Protokoll auf einem offenen Netz und löst ein Problem, das lange als theoretisch unmöglich galt. Dieselben Muster reichen bis in die KI hinein: das Training eines Frontier-LLM verlangt Tausende GPUs im Konzert, mit Daten-, Tensor-, Pipeline- und Sequenzparallelismus, und der Engpass ist oft eher Kommunikation und Synchronisation als Rechenleistung. Die begrifflichen Rahmen — Dijkstra, Hoare, Lamport, CAP — sind dauerhaft; die Ingenieurpraxis ändert sich schneller als in jedem anderen Teil der Informatik.