Das Unternehmen Google um den ersten Satz von Patches für den Linux-Kern einzuführen, die die notwendigen Komponenten zur Unterstützung des M:N-Thread-Modells implementieren. Die Initiative von Google ist mit der Eröffnung einer sich hinter verschlossenen Türen entwickelnden API verbunden für den Linux-Kern, der die Funktionalität des im Benutzerraum implementierten Multithreading-Subsystems gewährleistet, das das M:N-Thread-Modell verwendet. Dieses Subsystem wird von Google genutzt, um Dienste bereitzustellen, die minimale Latenzzeiten erfordern. Die Planung und Verwaltung der Thread-Verteilung erfolgt vollständig im Benutzerraum, was erheblich die Anzahl der Kontextwechsel reduziert, indem die Ausführung von Systemaufrufen minimiert wird.
Um den Betrieb des genannten Subsystems auf der Ebene des Linux-Kerns zu gewährleisten, wurde die SwitchTo-API implementiert, die drei grundlegende Operationen - wait, resume und swap (Wechsel) - anbietet. Zur Integration in den Kern wurde der Code für die neue Operation FUTEX_SWAP vorgeschlagen, die , ergänzt und eine Grundlage für die Erstellung von Multithreading-Bibliotheken im Benutzerraum bietet. FUTEX_SWAP kann auch zur Nachrichtenübertragung zwischen Aufgaben verwendet werden, analog zu RPC. Zum Beispiel erfordert die Übertragung einer Nachricht zwischen Aufgaben derzeit mindestens vier Aufrufe von FUTEX_WAIT und FUTEX_WAKE. Die Verwendung von FUTEX_SWAP ermöglicht jedoch den Einsatz einer einzigen Operation, die 5-10 Mal schneller ausgeführt wird.
Derzeit werden hauptsächlich die Thread-Modelle 1:1 und N:1 praktisch eingesetzt. Das 1:1-Modell wird in (-POSIX-Threads) und verwendet und impliziert eine direkte Zuordnung eines Threads im Benutzerraum zu einem Thread (Planungseinheit) auf Kernel-Ebene. Das N:1-Modell ist in implementiert, verlagert die Thread-Demultiplexierung in den Benutzerraum und erlaubt es, N Threads im Benutzerraum an einen Thread im Kernel zu binden, wobei der Kernel keine Informationen über die Benutzerdaten von Threads besitzt.
Der Hauptnachteil des 1:1-Modells sind die hohen Overheadkosten für den Kontextwechsel zwischen dem Kernel und dem Benutzerspeicher. Das N:1-Modell löst dieses Problem, schafft jedoch ein neues — da der Fluss im Kernel eine unteilbare Einheit der Ausführungsplanung darstellt, können Benutzerströme, die an einen Kernstroh im Betriebssystem gebunden sind, nicht über die CPU-Kerne skaliert werden und sind an einen einzigen CPU-Kern gebunden.
Das M:N-Modell ist hybrid und beseitigt alle oben beschriebenen Nachteile, indem es N Threads im Benutzerspeicher mit M Threads im Kernel des Betriebssystems abgleicht, was sowohl die Overheadkosten für den Kontextwechsel senkt als auch eine Skalierung über die CPU-Kerne ermöglicht. Der Preis dieses Ansatzes ist eine erhebliche Komplexität bei der Implementierung des Thread-Schedulers im Benutzerspeicher und die Notwendigkeit von Mechanismen zur Koordination der Aktionen mit dem Kernel-Scheduler.
Quelle: opennet.ru
