„Native POSIX Thread Library“ – Versionsunterschied

Die '''Native POSIX Thread Library''' ('''NPTL''') ist eine moderne Implementierung einer [[Thread (Informatik)|Threading]]-[[Programmbibliothek|Bibliothek]] für das Betriebssystem [[Linux]]. Sie wird in Verbindung mit der [[Glibc|GNU C Library]] (glibc) verwendet und erlaubt Linux-Programmen die Verwendung von [[pthreadsPortable Operating System Interface|POSIX-Threads]]-Threads (pthreads).

Seit der Kernel-Version 2.0 existierte für Linux die Threading-Bibliothek ''[[LinuxThreads]]'', deren grundlegende Design-Prinzipien unter Einfluss der 1996 vorhandenen Beschränkungen des [[Linux (Kernel)|Linux-Kernels]] und der libc5 zustande gekommen waren. Linux hatte keine echte Unterstützung für Threads im Kernel, kannte aber den ''clone()''-Systemaufruf, der eine Kopie des aufrufenden Prozesses mit identischem Adressraum erzeugte. LinuxThreads benutzte diesen [[Systemaufruf]], um Thread-Unterstützung so gut es ging im [[Ring (CPU)|Userspace]] zu simulieren. Die Bibliothek wurde zwar kontinuierlich verbessert, war aber schonkonzeptionell lange nicht mehr zeitgemäßveraltet und konzeptionell bedingt auch nicht reparierbar. Mittel der Wahl war daher eine Neuimplementierung der Threading-Bibliothekeingeschränkt.

* Sie benötigt einen Manager-Thread im Prozess, der weitere Threads erzeugt, wieder aufräumt und die [[Signal (Unix)|Signalbehandlung]] kanalisiert.

* Unter Last wird die [[Leistung (Informatik)|Performance]] schlecht, da das Signalsystem zum Zwecke derzur [[Prozesssynchronisation|Synchronisierung]] missbrauchtverwendet wird. Dies istbeeinträchtigt auch schlecht für die [[Stabilität]].

Um die bestehenden Probleme zu lösen, wurdewurden zusätzliche Infrastruktur im Kernel und eine neu geschriebene Threading-Bibliothek benötigt. Es wurden zwei konkurrierende Projekte gestartet: [[Next Generation POSIX Threads]] (NGPT) unter Leitung von [[IBM]] und NPTL unter Federführung der bei [[Red Hat]] angestellten Kernel- und glibc-Programmierer [[Ingo Molnár]] und [[Ulrich Drepper]]. AlsWeil sich abzeichnete, dass sich in der Praxis die NPTL durchsetzen würde, wurde das NGPT-Projekt Mitte 2003 eingestellt.

* POSIX-Konformität, um Userspace-[[Quelltext]] wieder besser portierbar zu machen

* effektive Verwendung von [[Symmetrisches Multiprozessorsystem|SMP]] und gute [[Skalierbarkeit]], um aufdie MehrprozessorsystemenLeistungsfähigkeit dieauf PerformanceMehrprozessorsystemen zu steigern

* niedrigewenig ErzeugungskostenErzeugungsaufwand pro Thread

Unter diesen Voraussetzungen begann Mitte 2002 die Arbeit an der neuen Native POSIX Thread Library. Im August/September 2002 wurde der Linux-Kernel 2.5 für die NPTL vorbereitet. Dazu war es notwendig, einige neue Systemaufrufe einzuführen und vorhandene zu optimieren. In ersten Benchmarks konnten nun auf einem IA-32-System innerhalb von 2 Sekunden 100.000 parallele Threads erzeugt werden; ohne NPTL dauerte allein die Erzeugung der Threads fast 15 Minuten. Trotz dieser bemerkenswerten Last blieb das SystemTestsystem während dieser Testsmit annähernd mit normalergleicher Geschwindigkeit benutzbar.

[[Red Hat Linux]] 9 war die erste Linux-Distribution, in der die NPTL in einem [[Patch_Patch (Software)|gepatchten]] 2.4er -Kernel verwendet wurde (und deren Benutzer dadurch bisweilen zu unfreiwilligen [[Entwicklungsstadium (Software)#BetatesterBeta-Version|Betatestern]] wurden). Inzwischen benutzen praktisch alle modernen Distributionen die NPTL, wenn sie einen Kernel der Version 2.6 oder höher verwenden.

NPTL funktioniert ähnlich wie ''LinuxThreads''. Der Kernel verwaltet immer noch Prozesse und keine Threads, und neue Threads werden mit einem von der NPTL aufgerufenen ''<code>clone()''</code> erzeugt. Die NPTL benötigt allerdings spezielle Kernelunterstützung und implementiert damit Synchronisationsmechanismen, bei denen Threads schlafen gelegt und wieder aufgeweckt werden. Dazu werden [[Futex]]es verwendet.

Die NPTL ist eine sogenannte 1:1-Threading-Bibliothek. Die vom Benutzer mit der ''<code>pthread_create()''</code>-Funktion erzeugten Threads stehen dabei in einer 1-zu-1-Beziehung mit Prozessen in den Scheduler-Queues des Kernels. Dies ist die einfachste denkbare Threading-ImplementationImplementierung. Die Alternative wäre m:n. Dabei existieren typischerweise mehr Threads im Userspace, als es Prozesse im Kernel gibt. Die Threading-Bibliothek wäre dann dafür verantwortlich, die Prozessorzeit auf die einzelnen Threads im Prozess zu verteilen. Mit diesem Konzept wären sehr schnelle [[Kontextwechsel]] möglich, da die Anzahl der notwendigen Systemaufrufe minimiert wird, andererseits würde aber die Komplexität erhöht, und es könnte leichter zu [[Prioritätsinversion]] kommen.

* [httphttps://wwwstatic.redhat.com/legacy/whitepapers/developer/POSIX_Linux_Threading.pdf The Native POSIX Thread Library for Linux] (PDF; 535&nbsp;kB)]