EMZETT.Threads
Kurz: Die kleinste ausführbare Befehlsfolge innerhalb eines Prozesses — moderne CPU-Kerne können dank “Simultaneous Multithreading” (z. B. Intel Hyper-Threading) oft zwei Threads pro Kern gleichzeitig bearbeiten.
Genauer: Ein Prozess kann mehrere Threads besitzen, die sich denselben Speicherbereich teilen, aber unabhängig voneinander laufen. Das ermöglicht z. B. einer App, gleichzeitig auf Nutzereingaben zu reagieren und im Hintergrund Daten zu laden.
Im Detail
Prozess vs. Thread
Ein Prozess besitzt einen eigenen, isolierten Speicherbereich, den kein anderer Prozess direkt einsehen kann — das Betriebssystem sorgt für diese Trennung, um zu verhindern, dass ein fehlerhaftes oder bösartiges Programm den Speicher eines anderen Programms beschädigt. Threads innerhalb desselben Prozesses teilen sich dagegen diesen gesamten Speicherbereich, haben aber jeweils einen eigenen Stack (für lokale Variablen und Funktionsaufrufe) und einen eigenen Befehlszeiger (welche Instruktion als Nächstes ausgeführt wird). Dadurch ist der Wechsel zwischen Threads (Context-Switch) deutlich billiger als zwischen ganzen Prozessen — es muss weniger Zustand gesichert und wiederhergestellt werden.
Race Conditions und Synchronisation
Der geteilte Speicherzugriff birgt aber auch Risiken: Greifen zwei Threads gleichzeitig unkoordiniert auf dieselben Daten zu, können inkonsistente Zwischenzustände entstehen (“Race Conditions”) — etwa wenn beide Threads gleichzeitig denselben Zähler um eins erhöhen wollen und dabei ein Inkrement verloren geht, weil beide vom selben veralteten Ausgangswert ausgehen. Typischerweise werden solche Konflikte mit Sperrmechanismen (Locks/Mutexes) verhindert: Ein Thread “sperrt” den Zugriff auf eine gemeinsam genutzte Ressource, bearbeitet sie, und gibt die Sperre erst danach wieder frei — andere Threads müssen währenddessen warten. Falsch eingesetzte Sperren können wiederum zu Deadlocks führen, bei denen sich zwei Threads gegenseitig blockieren, weil jeder auf eine Ressource wartet, die der andere gerade hält.
Hardware-Threads: Simultaneous Multithreading
Auf Hardware-Ebene (“logische Threads” pro CPU-Kern, zu unterscheiden von Software-Threads des Betriebssystems) erlaubt Simultaneous Multithreading (SMT, bei Intel als Hyper-Threading vermarktet) einem einzelnen physischen Kern, zwei Befehlsströme gleichzeitig zu verwalten. Die Grundidee: Moderne CPU-Kerne besitzen deutlich mehr interne Rechenlogik-Einheiten, als ein einzelner Befehlsstrom typischerweise gleichzeitig auslasten kann — viel Zeit verbringt eine CPU wartend, etwa während Daten aus dem Speicher nachgeladen werden. Wenn der eine logische Thread gerade auf einen solchen Speicherzugriff wartet, kann der physische Kern in der Zwischenzeit den zweiten logischen Thread weiterlaufen lassen und die sonst brachliegende Rechenkapazität nutzen.
Warum SMT nicht wie ein zweiter Kern wirkt
Das bringt spürbaren, aber begrenzten Mehrgewinn (typischerweise 15-30% mehr Durchsatz, nicht die vollen 100% eines zweiten echten physischen Kerns), da beide logischen Threads sich weiterhin dieselbe physische Rechenlogik, denselben Cache und dieselben Ausführungseinheiten teilen — sie können sich also gegenseitig ausbremsen, wenn beide gleichzeitig genau dieselbe interne Ressource benötigen. Aus diesem Grund zeigt ein Betriebssystem bei einer 8-Kern-CPU mit SMT zwar 16 logische Prozessoren an, die tatsächliche Rechenleistung liegt aber deutlich unter der von 16 echten physischen Kernen.