Seite 3: Fazit

Inhaltsverzeichnis

Skalierbarkeit

In puncto Skalierbarkeit wird der Fall haarig. Prozesse als Kernel-Entities kann jeder unixoide Kernel auf einem Multiprozessorsystem auf CPUs verteilen. Grundsätzlich können damit Kindprozesse im fork()-Ansatz auf verschiedenen CPUs wirklich parallel ablaufen. Nimmt die Anzahl der Prozessoren im Computersystem zu, skalieren Programme mit Nebenläufigkeiten in Prozessen grundsätzlich mit.

Bei Threads hängt das stark davon ab, wie die Threads implementiert sind. Kernel-Threads, bei denen Threads als Kernel-Entities ähnlich einem Prozess abgebildet werden, skalieren ebenso über Multiprozessoren wie Prozesse. User-Threads hingegen, bei denen die Thread-Implementierung in einer Bibliothek im User-Space erfolgt, skalieren nicht. Da das Programm selbst die Thread-Verwaltung übernimmt, existiert gegenüber dem Kernel nur eine einzige Kernel-Entity – der eine Prozess. In der Situation bleibt der Prozess mit seinen Threads auf einen Prozessor beschränkt, egal wie viele CPUs sonst noch im System existieren.

Wer jetzt glaubt, alle POSIX- seien als Kernel-Threads realisiert, der irrt. Die lange Odyssee von Linux hin zu Threads, die heute in den auf Kernel-Threads basierten NPTL (Native POSIX Thread Library) gipfelt, ist ein gutes Beispiel. Begann die Reise dort im User-Space. MINIX 3 beispielsweise befindet sich noch am Anfang der Reise. Es bewegt sich erst jetzt langsam in Richtung POSIX-Threads, das allerdings im User-Space. Auch aktuelle Implementierungsbeispiele, wie die POSIX-kompatiblen GNU Portable Threads oder die FSU-Threads für Ada, sind zwar hochgradig portabel, aber auf den User-Space beschränkt. Bezüglich Skalierbarkeit heißt es im Zweifel, einen näheren Blick auf das Zielsystem zu werfen.

Fazit

Die Frage, ob man OpenSSL-Programme eher mit Prozessen oder mit Threads implementieren sollte, hängt von vielen Details ab. Es ist an sich keine Frage von OpenSSL. Letzteres unterstützt beide Ansätze hinreichend gut und ohne Probleme – passendes Betriebssystem vorausgesetzt.

Der Trend weg von Kindprozessen und hin zu Thread ist in der Softwareentwicklung unverkennbar und grundsätzlich ein richtiger Schritt. Zumal die marktrelevanten und dominanten Systeme den Weg hin zum Kernel-Thread vollzogen haben. Für so manches altes Server-Programm, das nachträglich mit OpenSSL-Funktionen ausgestattet werden will, mag das Festhalten am guten alten fork() die wirtschaftlichere Alternative sein. Für Neuimplementierungen drängt sich die Thread-Variante auf. Die vereinfachte Kommunikation zwischen den Threads und die bei Kernel-Threads ebenfalls gegebene gute Skalierbarkeit sprechen dafür. Darüber hinaus hält OpenSSL die Programmierer durch die einfach zu implementierenden Callbacks von übermäßigem Overhead frei. Nach dem Implementieren der Callbacks lassen sich OpenSSL-Funktionen wie in Single-Thread-Prozessen nutzen. Der Aufwand für das Verwalten von Mutexes für eigene globale Datenstrukturen bleibt dabei erhalten. Dafür liegen diese nur einmal im Hauptspeicher und nicht mehrfach wie bei Prozesskopien.

Oliver Müller
ist Geschäftsführer der OMSE Software Engineering GmbH. Er leitet die Bereiche Software Engineering, Nearshoring und IT-Sicherheit. (ane)