Die POSIX Thread Bibliothek unter Linux & Fuss,
Futex und Furwocks

von: Franz-Josef Auernigg

Inhaltsverzeichnis

1 Die POSIX Thread Bibliothek unter Linux 1

1.1 Einleitung 1
1.2 Die weitere Entwicklung der Bibliothek 2
1.3 Probleme 2
1.4 Anforderungen an eine Neuimplementierung  3
1.5 Design Entscheidungen 4

1.5.1 Das 1-zu-1 oder M-zu-N Modell 4
1.5.2 Signal Behandlung 4
1.5.3 Der Managerthread  5
1.5.4 Synchronisations Primitiven 6
1.5.5 Speicheranforderungen  6
1.5.6 Kernel Erweiterungen 7

2 Fuss, Futex und Furwocks 9

2.1 Einleitung 9
2.2 Die Ziele der Implementierung 9
2.3 Die Implementierung 11

Zusammenfassung

Das erste Kapitel dieser Arbeit beschreibt die Neuerungen der POSIX Thread Bibliothek unter Linux. Das Hauptaugenmerk liegt dabei darauf, die POSIX-Bibliothek skalierbar zu machen und dabei Kernelerweiterungen zu benutzen, die bis 2003 noch nicht in der Bibliothek implementiert wurden. Weiters werden Kernelerweiterungen besprochen, die auf die Neuerungen der Thread Bibliothek abgestimmt wurden. Im zweiten Kapitel werden die in Kapitel eins angesprochenen Futexes genauer erläutert. Dazu wird erklärt was Futexes sind, warum sie eingesetzt werden, welche Ziele für die Implementierung wichtig waren und welche Mechanismen zur Umsetzung verwendet wurden.

Kapitel 1

Die POSIX Thread Bibliothek unter Linux

1.1 Einleitung

Nahezu alle modernen Betriebssysteme benutzen heute präemptives Multitasking um mehrere Aktivitäten auf die Resourcen Prozessor und Speicher aufzuteilen. Dazu gibt es die gängige Variante über Prozesse und die effizientere über Threads, welche zum Beispiel zur Implementierung von schneller Middleware nötig ist. Prozesse behandelt jede Unix-Implementierung gleich, bei Threads dagegen gibt es mehrere Möglichkeiten diese zu implementieren. Die folgende Abbildung zeigt einige davon. [LM03]

Abbildung 1.1: Überblick: Thread Bibliotheken [LM03] [Abbildung in der Downloaddatei vorhanden]

Nun möchte ich näher auf die Implementierung zu Linuxthreads eingehen. Die alte Implementierung der Posix Bibliothek von 1996/97 hatte den Nachteil, dass für die Umsetzung der 1-zu-1 Abbildung von User-level Threads auf Kernel Threads zusätzlich ein Thread gestartet werden musste, der sich um die Prozessverwaltung wie zum Beispiel um Signale und Thread Erzeugung kümmert. Das größte Problem war wohl, dass es keine geeigneten Synchronisationsprimitiven auf Kernelebene gab. Dies wurde durch Signale gelöst.

1.2 Die weitere Entwicklung der Bibliothek

In den folgenden 6 Jahren (1996-2002) wurde der Kernel in zwei Bereichen verbessert: Die ABI und der Linux-Kernel. Um die lokalen Daten bzw. den Stack von Threads schneller allozieren zu können, wurden Threadregister in der ABI eingeführt. Bei der Implementierung für IA-32 wurden dazu beispielsweise die Register %fs and %gs verwendet. Mittels dieser Register kann die Segmentadresse von Datenstrukturen bestimmt werden. Dazu muss in einer Deskriptor-Tabelle nachgesehen werden, was nur im Kernel Modus erlaubt ist und dadurch zu Performanzeinbußen führt, da zwischen Kernel- und Benutzermodus gewechselt werden muss. Eine Einschränkung durch die Adressierung mit Segment Registern ergibt sich daraus, dass in jenen nur 8192 Adressen unterschieden werden können. Insgesamt haben die erläuterten Erweiterungen jedoch eine Verbesserung der Performanz, der Flexibilität und die Vervollständigung der API gebracht. Die weitere Intention ist nun auch noch den Thread zur Verwaltung (Manager Thread) zu eliminieren.

1.3 Probleme

Die beschriebene Implementierung funktionierte bei vielen Anwendungen einwandfrei, hatte aber einige Probleme bei hoher Beanspruchung.

• Wenn beispielsweise der Manager-Thread eines Prozesses abstürzt, muss der Rest des Prozesses händisch aufgeräumt werden. Außerdem wird der Manager-Thread zum Flaschenhals, da er die Thread Erzeugung und Entfernung regelt.
• Das Signal System ist nicht POSIX konform, da beispielsweise ein Signal nicht an einen Prozess als ganzes gesendet werden kann, wenn dieser mehrere Threads hat. So ist es einem Benutzer nicht möglich, einen Prozess, der mehrere Threads hat, mittels SIGSTOP zu stoppen bzw mit SIGCONT fortzusetzen. [SIGC]
• Die Verwendung des Signal Systems zur Implementierung von Synchronisationsprimitiven ist problematisch, da die Antwortzeit von Operation sehr hoch ist und die Signalverarbeitung noch komplizierter wird. Wenn zum Beispiel ein Thread wartet bis eine Bedingung eintritt, legt er sich bis dahin schlafen. Dabei kommt es öfters vor, dass er zuvor aufgeweckt wird, was natürlich umgangen werden muss. [Spur]

[...]