Einführung in das Betriebssystem BeOS 5

- multiprozessor optimized -

 

Das BeOS ist komplett auf präemptives Multithreading ausgelegt. Jedes Fenster belegt einen Thread, der sich nur um Position und Größe des Fensters und um das Redraw der Fensterelemente kümmert, und einen Thread, der sich mit dem Redraw des Fensterinhalts und den eintretenden Events befaßt. Ein Menü erzeugt einen eigenen Thread, sobald es angewählt wird, und auch Funktionen wie DrawBitmap teilen selbständig die Arbeit auf zwei Threads auf. Ebenso läuft der Zugriff auf die Festplatte in einem eigenen Thread, der wiederum über einen Port mit dem Rest des Systems in Verbindung steht. In der Praxis bedeutet das: Skaliert der User das Fenster eines Programms, das Bilder von Festplatte lädt und als Film abspielt, ist daran gut ein halbes Dutzend Threads beteiligt. Die Verwendung von zwei oder mehr CPUs bringt also einen klaren Zeitvorteil, da tatsächlich mehr Dinge auf einmal erledigt werden.

Dabei unterscheidet BeOS zwischen real-time threads (Priorität >= 100) und time-sharing threads (Priorität < 100). Die Prioriäten für die meisten Anwendungen liegen im Bereich zwischen 5 und 30. real-time threads sind Programmteile, die zeitabhängig sind und daher keinen Aufschub dulden, zum Beispiel Audio-Stream-Controller oder Echtzeitvideoverarbeitung. Diese Threads werden umgehend (in Reihenfolge ihrer Priorität) ausgeführt und können (außer von real-time threads höherer Priorität) nicht unterbrochen werden, so lange, bis sie `schlafen´ oder `blockieren´. time-sharing threads sind alle anderen Programmteile. Sie werden nur ausgeführt, wenn alle real-time threads abgelaufen sind.
Die verfügbare Rechenzeit der CPUs wird vom Scheduler in Quanten (zu 3 ms) eingeteilt und gemäß der Prioritäten an die einzelnen Threads vergeben. Die Chance eines Thread auf der Warteliste, ein Zeitquantum zugewiesen zu bekommen, wächst exponentiell mit seiner Priorität.
Dieses System gewährleistet, daß Echtzeitanwendungen zuverlässig arbeiten und das Benutzer-Interface (aufgrund der Verteilung der Prioritäten) weitgehend unabhängig von der CPU-Belastung gute Ansprech- und Reaktionszeiten hat. Als besondere Eigenschaft bleibt noch zu erwähnen, daß es für die meisten Anwendungen nebensächlich ist, wieviele CPUs der Computer besitzt, in der Tat weiß man ohnehin niemals, auf welcher CPU zu welcher Zeit ein Thread laufen wird.

Damit aber nicht nur viele Dinge gleichzeitig laufen, sondern auch noch unter den Threads Disziplin und Ordnung herrscht, gibt es die Semaphore. Ein Semaphor ist wie ein Schloß mit einer genau festgelegten Anzahl von Schlüsseln. Wenn ein Thread versucht, sich ein Semaphor `anzueignen´, bekommt er es entweder (falls noch genug `Schlüssel´ vorhanden sind), oder er wird eingefroren, bis ein anderer Thread die Semaphore freigibt. Es können maximal so viele Threads gleichzeitig ein Semaphor belegen, wie vorher festgelegt wurde (meistens genau einer, um Threads bei der Benutzung gemeinsamer Daten wechselseitig auszuschließen). Man benutzt Semaphore

• um Threads zu synchronisieren,
• um sicherzustellen, daß bestimmte Ressourcen nur von einer limitierten Zahl von Threads gleichzeitig benutzt werden,
• um sicherzustellen, daß Threads eine bestimmte Reihenfolge einhalten

Trotz allem darf man auch vom BeOS keine `Zauberei´ erwarten. Um rechenintensive Programmteile, die überwiegend isoliert ablaufen (Raytracer, Fraktalgenerator etc.) zu optimieren, führt kein Weg daran vorbei, den Algorithmus so zu modifizieren, daß mehrere Threads jeweils einen Teil der Arbeit übernehmen. Beim Beispiel des Fraktalgenerators kann dies unter anderem dadurch erfolgen, indem n Threads nur jede n-te Zeile berechnen.