Multithreading in Go: CPU, Caches und Performance | Analyse

Multithreading in Go: Wie CPU, Caches und der Scheduler die Performance beeinflussen

Moderne Go-Anwendungen setzen intensiv auf Parallelität, doch viele Entwickler verstehen nicht vollends, was unter der Haube abläuft, wenn mit mehreren CPU-Kernen gearbeitet wird. Dieser Artikel taucht tief in die Low-Level-Mechanismen ein, die die Leistung von Multithreading-Programmen beeinflussen: von den Feinheiten des Kontextwechsels bis zur Cache-Kohärenz. Wir erklären, warum atomare Operationen und Memory-Barrieren existieren und wie ihre Eigenarten sich in realen Szenarien auswirken.

Multitasking-Mechanismen: Kooperativ vs. Präemptiv

Das Kernproblem bei Single-Core-Systemen ist die gleichzeitige Handhabung mehrerer Aufgaben. Es gab zwei Varianten der Lösungen:

• Kooperatives Multitasking — Aufgaben geben die CPU freiwillig über Systemaufrufe wie sched_yield() frei. Der Nachteil liegt auf der Hand: Eine hängende Aufgabe blockiert das gesamte System (wie unter Windows 3.1).

• Präemptives Multitasking — Aufgaben werden durch einen Timer gewaltsam unterbrochen. Wichtige Phasen:

- Erzeugung eines Hardware-Interrupts

- Speicherung des Kontexts der aktuellen Aufgabe im RAM

- Auswahl einer neuen Aufgabe durch den Scheduler

- Wiederherstellung des Kontexts

Es ist entscheidend zu verstehen, dass der Task-Kontext umfasst:

• Registerwerte (RAX, RBX usw.)
• Instruction Pointer (RIP)
• Stack Pointer (RSP)
• Flags-Register (RFLAGS)
• Stack-Daten

Der Kontextwechsel erfordert das Speichern dieser Daten im RAM, was Overhead verursacht. Auf modernen CPUs dauert ein Kontextwechsel 200–300 Zyklen – vergleichbar mit der Ausführung Dutzender Anweisungen.

Architektur von Multi-Core-Systemen und Cache-Hierarchie

Der Wechsel zu Multi-Core-Prozessoren brachte ein neues Problem mit sich: die Synchronisation des Zugriffs auf gemeinsamen Speicher. Um die Lösungen zu verstehen, zerlegen wir die Cache-Hierarchie:

L1-Cache

• Größe: 32–64 KB
• Latenz: ~4 Zyklen
• Geteilt in Anweisungen (L1i) und Daten (L1d)
• Gebunden an einen physischen Kern

L2-Cache

• Größe: 256 KB – 1 MB
• Latenz: 10–15 Zyklen
• Meist an einen Kern gebunden

L3-Cache

• Größe: 8–40 MB
• Latenz: 30–50 Zyklen
• Gemeinsam für alle Kerne

Wichtiger Punkt: Der Prozessor verwaltet die Caches über einen Hardware-Controller. Das Betriebssystem und Anwendungen können die Datenplatzierung nicht direkt steuern. Das führt zu Situationen, in denen verschiedene Kerne mit veralteten Datenkopien arbeiten.

MESI-Protokoll und Cache-Kohärenz

Die Cache-Kohärenz wird durch das MESI-Protokoll (Modified, Exclusive, Shared, Invalid) geregelt. Jede Cache-Zeile (typischerweise 64 Bytes) hat einen von vier Zuständen:

• Modified: Daten in diesem Cache geändert und vom RAM abweichend
• Exclusive: Daten stimmen mit RAM überein, nur für diesen Kern zugänglich
• Shared: Daten stimmen mit RAM überein und können in anderen Caches vorhanden sein
• Invalid: Daten sind veraltet und nicht nutzbar

Beispiel für eine Schreiboperation:

• Kern A liest die Variable → Shared-Zustand
• Kern B liest dieselbe Variable → Shared-Zustand
• Kern A schreibt einen neuen Wert → Invalidierungsanfrage
• Kern B erhält die Anfrage und setzt die Zeile auf Invalid

Dieser Mechanismus erzeugt versteckte Verzögerungen: Konkurrierende Schreibzugriffe zwingen Kerne, Signale über den Bus auszutauschen, was 100–300 Zyklen dauern kann.

Praktische Implikationen für Go-Entwickler

Das Verständnis dieser Mechanismen ist unerlässlich bei der Arbeit mit:

• Atomaren Operationen: LOCK XCHG-Anweisungen gewährleisten Atomizität durch Bus-Sperrung
• Memory-Barrieren: mfence steuert die Reihenfolge der Anweisungsausführung
• CPU-Affinität: Binden von Goroutines an bestimmte Kerne über GOMAXPROCS

Beispiel für False Sharing:

var data [2]int64

// Goroutine 1
for {
    data[0]++
}

// Goroutine 2
for {
    data[1]++
}

Obwohl unterschiedliche Array-Elemente angesprochen werden, landen sie in derselben Cache-Zeile (64 Bytes). Schreiben auf data[0] macht die Zeile für den zweiten Kern ungültig und löst ständige Synchronisation aus. Lösung: Padding hinzufügen:

var data [2]struct{
    value int64
    _     [56]byte // Padding auf 64 Bytes
}

Wichtige Punkte

• Kontextwechsel speichert Zustände im RAM und verursacht ~200-Zyklen-Verzögerungen
• Cache-Kohärenz über MESI erzeugt Overhead bei konkurrierenden Schreibzugriffen
• False Sharing kann die Leistung um 2–3 Größenordnungen einbrechen lassen
• Atomare Operationen nutzen Bus-Sperrung oder Cache-Protokolle (architekturabhängig)
• Kenntnis der Cache-Hierarchie ermöglicht Optimierung von Datenstrukturen auf Cache-Zeilengröße

Go-Entwickler laufen bei hochbelasteten Diensten oft in diese Fallen. In verteilten Systemen kann schlechte Cache-Nutzung bei Tausenden Anfragen pro Sekunde unerwartete Latenz verursachen. Der zentrale Punkt: Effektive Parallelität berücksichtigt nicht nur die App-Logik, sondern auch Hardware-Eigenheiten.

Für tiefere Einblicke: Schaut euch die Assembly-Ausgabe des Go-Compilers mit der -S-Flag an und nutzt Profiler wie perf, um Cache-Verfehlungen und Kontextwechsel zu messen. So werden Engpässe sichtbar, die im Quellcode unsichtbar bleiben.

— Editorial Team