7.17. Userspace/ Micro / Green threads

Microthreads bzw. green threads sind sog. lightweight threads, bzw. userspace threads, die in Interpretern (JAVA, Python, Perl) alternativ zu native threads verwendet werden. Userspace Threads sind Threads, die ohne die Mechanismen der Kernel - Threads auskommen. Der Kernel sieht nur einen Prozess, davon, daß dieser noch andere Threads enthält, sieht dieser nichts. Es gibt aber auch Mischformen, wo der Kernel trotzdem von den User-Spache Threads erfährt, bekannt auch als "two-level" oder "hybrid systems". Mit den Kommandos pstack, ptrace, nm und ps kann man Linux gut untersuchen. Threads können so, unabhängig von der Implementierung der Kernel Threads (NGPL, NTPL) ohne Kernel - Locks und den riesigen RAM - Verbrauch (C-Stack) je Kernel - Thread (1 MByte) schnell und sparsam erzeugt werden. Der Interpreter selber übernimmt die Zeitscheiben - Verteilung. Weil Linux Kernel 2.4 bei der Erzeugung von Threads erhebliche Probleme mit der Geschwindigkeit hatte, siehe Abschnitt 7.7, hat SUN den JAVA Interpreter in zwei Versionen angeboten. Einmal mit kernel threads und einmal mit green threads, wo der JAVA Interpreter selber mit sehr geringem Overhead von unter 200 Byte! einen neuen JAVA - Thread generieren konnte. Dasselbe gilt auch für den Stackless Python Interpreter, welcher in der Lage ist, in mehr als 100.000 Threads je eine Netzwerkverbindung via TCP/IP aktiv zu bedienen. Die Hardware - Lösung Ironport und das Echtzeit Multi - User Game EVE (CPP Games) zeigen äußerst eindrucksvoll, wozu Interpreter bei intelligenter Programmierung fähig sind, mehr hierzu siehe auch Vortrag über Stackless Python. Diese Lösung mit Stackless Python, siehe www.python.org hat mehrere Vorteile, wie z.B. keine Kernel - Locks, keinen C-Stack/Heap Overhead von ca. 1 Megabyte/Thread, wie bei 1:1 Threads, und enorm wenig Speicherplatzverbrauch je Thread (unter 200 Byte!). Die Ironport - Lösung ist als einziger Mailserver in der Welt in der Lage, 100.000 Mails gleichzeitig zuzstellen, ebenso, wie Stackless Python bei EVE überhaupt erst ermöglichte, daß mehrere 100.000 Spieler gleichzeitig sich durch gemeinsame Welten bewegen und interagieren konnten.

Test haben ergeben, daß Stackless Python nicht nur äußerst stabil, sondern auch besser für Echtzeit - Anwendungen geeignet ist, als Real-Time Extensions in Linux oder anderen Echtzeit - Betriebssystemen, wie z.B. Ampel - oder Maschinen - Steuerungen, welche starke Synchronisation zwischen den Threads erfordern. Mit Python als Interpreter - Sprache kann man, ebenfalls, wie in JAVA, sogar Semaphoren steuern, mehr hierzu siehe Abschnitt 7.15. Diese sind für Threads quasi "Ampeln", die unter Python einzelne Code - Abschnitte davor bewahren, daß mehr als ein Thread diesen Bereich "betritt" und Code darin ausführt. (Zur Erinnerung - Threads teilen sich Code und Daten...). Unbedingt notwendig ist hier ASYNC I/O, wobei Datenströme von vielen TCP/IP Verbindungen gleichzeitig in Hin - und Rückrichtung von Threads bedient werden. Mehr hierzu siehe Python Microthreads, Abschnitt 7.10 und Abschnitt 9.1. Hier ein Tutorial von IBM über: Python Threads und Semaphoren.