SIEGEN - Betriebssysteme für Kleinrechner, die in zunehmend spezielleren Anwendungen zum Einsatz kommen sollen, müssen zukünftig in immer kürzeren Zeitabständen und mit sinkenden Kosten entwickelt werden können. Mit den bisherigen Methoden und Sprachen ist dies allerdings nicht erreichbar.
Daher vollzieht sich im Bereich der Betriebssysteme für kleine Ein- und Mehrplatzsysteme bereits eine relativ eigenständige Entwicklung. Neben klaren Systemstrukturen, wie dem Schichtenmodell, werden sichere Sprachen entwickelt, mit denen dem Systementwickler ein wirkungsvolles Werkzeug zur Programmierung funktionsoptimaler und sicherer Betriebssoftware in die Hand gegeben wird.
Ein Systementwickler, der ein Betriebssystem für einen Kleinrechner mit dialog- und stapelorientierten Funktionen entwickeln soll, kann dieses Problem nicht einfach dadurch lösen, daß er entsprechende Algorithmen der klassischen Betriebsarten miteinander kombiniert. Er muß vielmehr den globalen Systemaspekt und eine klare Struktur vor Augen haben sowie die Kunst besitzen, auf Luxusfunktionen" verzichten zu können. Solche Luxusfunktionen für ein kleines System sind beispielsweise Funktionen zum Umordnen einer Hintergrundwarteschlange oder Ein- und Ausgabespooling, wenn die Arbeitsweise der Benutzer mit dem System nur ein Ausgabepooling erforderlich macht.
Neben dieser notwendigen Funktionsoptimierung gewinnen die Korrektheit und Fehlerfreiheit der Betriebssysteme immer mehr an Bedeutung. Während es früher unter Systemprogrammierern geradezu als schick galt, einen Fehler pro einer gewissen Anzahl von Assemblerbefehlen zu haben, um dadurch die Komplexität ihrer Betriebssoftware zu demonstrieren, könnte diese Einstellung für einen Hersteller heute ernsthafte Folgen haben.
Releasepolitik wird zu schwerfällig
Rechnet man für das Betriebssystem eines Mehrplatzsystems etwa 20 000 Assemblerbefehle, so muß nach der klassischen IBM OS/360-Formel (1 Fehler/1000 Statements) jeder Kunde im schlechtesten Falle 20mal zum Zweck des Austausches des Betriebssystems besucht werden. Bei der heutigen Kostensituation muß dies zwangsläufig in die roten Zahlen führen.
Technologische Veränderungen (Speicher, Peripherie) und neue Benutzerfunktionen bewirkten in der Vergangenheit immer Anpassungen der Betriebssysteme. Dies führte zu einer nahezu unüberschaubaren Releasepolitik. Heute vollzieht sich der technologische Wandel derart rasch, daß nicht mehr nur lokale Verbesserungen der Hardware vorgenommen, sondern komplette neue Hardware-Architekturen entwickelt werden.
Eine Anpassung bestehender Betriebssysteme erscheint unzweckmäßig, da die Funktionsoptimierung nicht mehr durchgehalten werden kann und die Unsicherheit und Fehleranfälligkeit des Systems rasch zunehmen. Statt dessen wäre es anzustreben, bei technologischen Fortschritten ein neues Betriebssystem oder eine Betriebssystemfamilie zu entwickeln und so für das angepeilte Marktsegment ein optimales System zu schaffen.
Diese drei bestimmenden Faktoren - Funktionsoptimierung, Korrektheit und technologischer Wandel - machen es vor allem im Bereich der Kleinrechner erforderlich, Betriebssysteme in kurzer Zeit nach industriellen Produktionsmaßstäben sicher und zuverlässig entwickeln und konstruieren zu können.
Systementwurf mit Nucleussprachen
Dazu ist es erforderlich
a) neue und relativ stabile Softwarearchitekturen zu entwickeln,
b) Entwurfs- beziehungsweise Nucleussprachen zu entwickeln und einzusetzen, die die Strukturierung der Betriebssoftware unterstützen und mit denen sichere und zuverlässige Betriebssysteme programmiert werden können.
Die wichtigste Forderung an eine geeignete Nucleussprache ist die der expliziten Einbettung der sogenannten Nucleuskonzepte in die Sprache. Versteht man unter einem Betriebssystemnucleus alle wesentlichen Programmierkonzepte, die zur Programmierung der Betriebssystemfunktionen dienen - wie etwa das Prozeßkonzept -, dann bedeutet diese Forderung, diese Konzepte in die Sprache einzubetten und damit verfügbar zu machen.
Aus der Menge der in der Literatur diskutierten Konzepte sind folgende für den Entwurf und die Konstruktion eines Betriebssystems für ein kleines System ausreichend:
* Definitionsmöglichkeiten skalarer und strukturierter Datentypen,
* Definitionsmöglichkeiten von Datentypen, auf die nur a-priori-definierte Operationen erlaubt sind (class concept),
* das fundamentale Konzept des Prozesses,
* Synchronisations- und Kommunikationskonzepte (wie "monitor und mailbox").
Speicherknappheit und Laufzeiten keine Argumente mehr
Weiterhin müssen die vorgenommenen Abstrahierungen eines geschichteten Betriebssystems in der Nucleussprache formulierbar sein. Die Nucleussprache darf daher keine "uni-level"-Sprache sein. Des weiteren soll die Beschreibung der bei der Strukturierung entstehenden Komponenten funktional sein; man sollte also aus der Betrachtung des statischen Programmtextes die Funktion einer Komponente verstehen können. Die Nucleussprache darf auch keinerlei unsichere Merkmale wie Zugriff auf Hauptspeicheradressen oder Gebrauch von Maschinenanweisungen aufweisen.
Mit einer solchen Nucleussprache wird dem Systemdesigner ein relativ komplexes, jedoch hochwirksames Konstruktionsmittel in die Hand gegeben, und es ist offensichtlich, daß es nicht nur die, Speicher- und Laufzeitargumente waren, die die Entwicklung solcher Sprachen bis vor einigen Jahren behinderten. Mit der abnehmenden Bedeutung der Speicher- und Laufzeiteinwände und mit wachsendem Verständnis der erforderlichen Nucleus- und Betriebssystem konzepte wurde jedoch der Grundstein zur Entwicklung geeigneter Sprachen gelegt. Concurrent Pascal, CSP/K und mit einigen Abstrichen Path Pascal und Modula erfüllen bereits wesentliche der erhobenen Forderungen.
Insbesondere mit Concurrent Pascal sind bereits Betriebssysteme im industriellen Bereich entwickelt worden, die alle Erwartungen in puncto Korrektheit, Fehlerfreiheit und vor allem kurzer Entwicklungszeit voll erfüllen.
Im Bereich der Softwarearchitektur bildet die Schichtenarchitektur die Grundlage vieler Betriebssystementwicklungen. Die einzelnen Abstraktionsebenen. die in einem Schichtenmodell nach Bild 1 entstehen, können als Menge von Operationen (Befehlen) und Datenobjekten angesehen werden, die dem Systementwickler oberhalb dieser Ebene zur Verfügung stehen. Anders ausgedrückt dienen die Schichten unterhalb einer Abstraktionsebene Lj zur Interpretation (Abwicklung) der Operationen dieser Ebene und fungieren damit gewissermaßen als Prozessor, der als virtueller Prozessor bezeichnet wird.
Prozeßabläufe in Schichten und Schalen
In Verbindung mit der Nucleussprache nimmt die unterste Schicht in einem solchen Architekturmodell eine besondere Stellung ein. Sie ist nicht nur eine Abstraktionsebene, sondern eine vollständige Sprachebene, die die aufgezählten Konzepte wie Prozeß und Kommunikationskonzepte bereitstellen muß. Obwohl der Prozeßbegriff ein neutraler Begriff der Betriebssystemtheorie ist, gibt es bis heute keine allgemein akzeptierte Prozeßdefinition. Dennoch hat sich vor allem in den englischsprachigen Ländern eine pragmatische Prozeßdefinition eingebürgert, die vor dem Hintergrund des Nucleusgedankens und der Nucleussprache sowie der Schichtenarchitektur zu sehen ist. Danach ist ein Prozeß eine Folge von Instruktionsabwicklungen eines Programms auf einem realen oder virtuellen Prozessor.
In einem Schichtenmodell mit einem Nucleus gibt es dann Nucleusprozesse oder Prozesse 1. Art als Instruktionsabwicklungsfolge derjenigen Programme die diesen Nucleus bilden. Nucleusprozesse laufen daher immer auf dem realen Prozessor ab. Betriebssystemprozesse oder Prozesse 2. Art sind Abwicklungsfolgen von Instruktionen oberhalb der Nucleusebene und werden explizit deklariert. Betriebssystemprozesse laufen auf einem virtuellen Prozessor ab. Schließlich bilden Ereignisfolgen, bestehend aus der Abwicklung der Programminstruktionen von Benutzerprogrammen, die Benutzerprozesse oder Prozesse 3. Art. Diese Klassifikation führt zu einem Schalenmodell nach Bild 2.
Es ist zu erwarten, daß in Zukunft mit wachsendem Verständnis der Nucleuskonzepte Hardwarearchitekturen entwickelt werden, die diese Konzepte direkt unterstützen. Mit Komponenten, die explizit als Prozesse in einem Betriebssystem vereinbart werden können, tritt der Aspekt der Parallelität in den Hintergrund, und die Strukturierungsmöglichkeit gewinnt an Bedeutung. Damit wird es möglich, komplette Betriebssysteme in Mannmonaten oder wenigen Mannjahren zu entwickeln und ein ungeeignetes System auch einmal in den Papierkorb zu werfen, bevor es mit hohem Kostenaufwand für den Markt zurechtgebogen wird. Auf lange Sicht werden auch komplexe Softwaresysteme wie Datenbanken und Datenkommunikationssysteme in den Betriebssystementwurf einbezogen werden und in Form von Prozessen und Kommunikationskomponenten strukturiert werden.
Literatur: Brinch Hansen, P.: Concurrent Pascal: A Programming Language for Operating System Design: Information Science, Technical Report No. 10, April 1975.
Nehmer, J.: Betriebssysteme für Kleinrechner. Angewandte Informatik, Nr. 1, 1977.
* Dr. Helmuth Seidel ist Systementwicklungsingenieur bei der Philips Data Systems GmbH, Siegen.