Google Zur Integration in den Linux-Kernel wurde das erste Patchset mit der Implementierung der Komponenten erstellt, die für den Betrieb des M:N-Thread-Modells erforderlich sind. Die Initiative von Google ist mit der Eröffnung eines vorher geheim gehaltenen APIs verbunden. für den Linux-Kernel, der die Ausführung eines multithreaded Subsystems im Benutzermodus mit dem M:N-Thread-Modell ermöglicht. Dieses Subsystem wird von Google verwendet, um Dienste bereitzustellen, die minimale Latenzen erfordern. Die Planung und Verwaltung der Thread-Verteilung erfolgt ausschließlich im Benutzermodus, was die Anzahl der Kontextwechsel erheblich reduziert, indem die Ausführung von Systemaufrufen minimiert wird.
Um das genannte Subsystem auf Kernel-Ebene zu unterstützen, wurde die SwitchTo-API implementiert, die drei grundlegende Operationen - wait, resume und swap (Wechsel) - anbietet. Für die Integration in den Kernel wurde der Code einer neuen Operation FUTEX_SWAP vorgeschlagen, die FUTEX_WAIT und FUTEX_WAKE ergänzt. , und bietet die Grundlage für die Erstellung von mehrgängigen Bibliotheken im Benutzerspeicher. FUTEX_SWAP kann auch zur Nachrichtenübertragung zwischen Aufgaben verwendet werden, ähnlich wie RPC. Derzeit erfordert die Übertragung einer Nachricht zwischen Aufgaben mindestens vier Aufrufe von FUTEX_WAIT und FUTEX_WAKE. Der Einsatz von FUTEX_SWAP ermöglicht hingegen eine einzige Operation, die 5 bis 10 Mal schneller ausgeführt wird.
Derzeit werden in der Praxis hauptsächlich 1:1- und N:1-Thread-Modelle verwendet. Das 1:1-Modell wird in (POSIX-Threads) und verwendet und bedeutet eine direkte Zuordnung von Benutzerthreads zu Threads (Scheduleinheiten) auf Kernel-Ebene. Das N:1-Modell ist in implementiert und verlagert die Thread-Diskretion in den Benutzerspeicher, sodass N Benutzerthreads an einen Kernel-Thread gebunden werden können, ohne dass der Kernel Informationen über die Benutzerthreads hat.
Ein wesentlicher Nachteil des 1:1-Modells sind die hohen Overhead-Kosten für den Kontextwechsel zwischen dem Kern und dem Benutzerraum. Das N:1-Modell löst dieses Problem, bringt jedoch eine neue Herausforderung mit sich – da der Datenfluss im Kernel eine unteilbare Einheit zur Ausführung ist, können Benutzerströme, die an einen Fluss im Betriebssystem-Kernel gebunden sind, nicht über die CPU-Kerne skalieren und sind an einen einzelnen CPU-Kern gebunden.
Das M:N-Modell ist hybrid und beseitigt alle zuvor beschriebenen Nachteile, indem es N Ströme im Benutzerraum mit M Strömen im Betriebssystem-Kernel abgleicht. Dies ermöglicht es sowohl die Overhead-Kosten für den Kontextwechsel zu reduzieren als auch die Skalierung über die CPU-Kerne zu gewährleisten. Der Preis für diese Variante ist eine erhebliche Verkomplizierung der Implementierung des Thread-Schedulers im Benutzerraum sowie die Notwendigkeit von Mechanismen zur Synchronisation mit dem Scheduler des Kernels.
Quelle: opennet.ru
