5.2 Aufgaben eines Betriebssystems
Zusammengefasst verwaltet ein Betriebssystem die Betriebsmittel eines Computers – also Rechenzeit, Speicher oder I/O-Geräte – und ermöglicht dem Benutzer das Ausführen von Programmen. Zwei weitere, jedoch eher indirekte Aufgaben, die wir bisher noch nicht besprochen haben, sind Abstraktion und Virtualisierung.
5.2.1 Abstraktion
Abstraktion haben wir von Anfang an als selbstverständlich betrachtet. Niemand möchte Maschinencode schreiben oder sich direkt mit dem Prozessor auseinandersetzen. Man möchte viel lieber auf ein hübsches Symbol auf dem Desktop klicken, um ein bestimmtes Programm zu starten. So weit, so gut.
Ein weiteres gutes Beispiel sind die bereits vorgestellten Syscalls. Sie abstrahieren die komplexen Fähigkeiten des Betriebssystems in wenige, konkret gegebene Funktionsaufrufe. Eine ebenfalls sofort einsichtige Anwendung des Abstraktionsprinzips gibt es beim Dateisystem. Eine Festplatte wird schließlich über ihre geometrischen Eigenschaften adressiert, also über ihre Zylinder, Köpfe und Sektoren. [Fn. Teilweise wird aber auch schon vom Controller davon abstrahiert, so dass das Betriebssystem es nur noch mit abstrakten Blocknummern zu tun hat.] Für den Benutzer werden diese unhandlichen Eigenschaften jedoch auf Dateien und Verzeichnisse abgebildet, und diese werden sogar mit diversen Rechten und anderen Eigenschaften versehen. Die Syscalls dienen nun dazu, diese abstrahierte Funktionalität aus Programmen heraus nutzen zu können.
Geräte als Dateien
Unter Unix-Systemen wie zum Beispiel Linux und BSD werden verwaltete Geräte auf spezielle Dateien im /dev-Verzeichnis abgebildet. Das hat den Vorteil, dass man auch für die Benutzung von I/O-Geräten Rechte vergeben kann und sich die Handhabung nicht wesentlich von der des restlichen Systems unterscheidet.
5.2.2 Virtualisierung
Virtualisierung ist eine weitere wichtige Aufgabe des Betriebssystems. Der Ausdruck bezeichnet in der Informatik eine Ressourcenteilung möglichst ohne ungünstige Nebenwirkung für die Benutzer. Für den Benutzer beziehungsweise für sein Programm sieht es nämlich so aus, als stünde die Ressource ausschließlich ihm zur Verfügung.
Virtuelle Prozessoren und Multitasking
Das erste Beispiel für Virtualisierung kennen wir bereits: die Virtualisierung des Prozessors. Das bereits erwähnte präemptive Multitasking ermöglicht das quasiparallele Ausführen von mehreren Programmen. Dazu wird, wie wir bereits festgestellt haben, die verfügbare Prozessorzeit in viele i.d.R. gleich große Zeitscheiben (Timeslices) unterteilt, die vom Betriebssystem nun einzelnen Programmen zugewiesen werden. Im Folgenden kann dann jedes Programm rechnen, als hätte es den gesamten Prozessor für sich allein. Es merkt nichts von den Unterbrechungen und von anderen parallel laufenden Programmen.
Abbildung 5.4 Multitasking
Um dies umzusetzen, startet der Kernel einen Timer, um nach dem Ablauf der Zeitscheibe des Programmes wieder aufgeweckt zu werden. Ist der Timer angelaufen, wird über einen Interrupt der Kernel wieder aufgeweckt – vorher werden jedoch alle Prozessorregister gesichert, so dass das Programm später ohne Probleme wieder fortgesetzt werden kann.
Virtueller Speicher
Wie schon der Name dieses ebenfalls bereits erwähnten Prinzips sagt, handelt es sich hier um eine Virtualisierung des Speichers. Jedes Programm hat den Eindruck, dass ihm der gesamte Hauptspeicher zur Verfügung steht. Alle Adressen können benutzt werden, ohne dass ein Programm von anderen, zur selben Zeit laufenden Programmen etwas merken würde. Die anderen Programme haben natürlich ebenfalls ihren eigenen virtuellen Speicher.
Greift ein Programm auf eine (virtuelle) Adresse zu, wird diese von der MMU in die entsprechende reale Adresse im Hauptspeicher übersetzt. Das Setup, also die Verwaltung der MMU und des Hauptspeichers, übernimmt dabei wieder das Betriebssystem. Dieses wird auch durch einen Interrupt informiert, falls ein Speicherbereich, auf den ein Programm gern zugreifen möchte, auf die Festplatte ausgelagert wurde. In der Behandlungsroutine des Interrupts kann das Betriebssystem diesen Speicherblock nun wieder in den Hauptspeicher kopieren und die fehlgeschlagene Anweisung des unterbrochenen Programms noch einmal wiederholen – diesmal ist die betreffende virtuelle Adresse im Hauptspeicher eingelagert, und die Adressübersetzung der MMU schlägt nicht mehr fehl.
Speicher anfordern
Diese vom Betriebssystem zu erledigende Verwaltungsarbeit für den virtuellen Speicher zeigt auch die Relevanz eines Syscalls auf, der für ein Programm neuen Speicher anfordert. Der meist malloc() genannte Funktionsaufruf sorgt dafür, dass die Memory Management Unit entsprechend initialisiert wird. Dann kann dem Programm die virtuelle Adresse zurückgegeben werden, unter der der angeforderte Speicherbereich ansprechbar ist.
Griffe ein Programm auf eine virtuelle Adresse zu, die noch nicht initialisiert ist, würde die MMU natürlich wieder das Betriebssystem über einen Interrupt informieren. Das Betriebssystem sähe nun nach, ob der betreffende Speicherbereich vielleicht ausgelagert wäre – aber das ist er nicht. Es liegt also ein klassischer Speicherzugriffsfehler vor, bei dem ein Programm normalerweise beendet wird. Falls so etwas auftritt, liegt meist ein etwas komplizierterer Programmierfehler vor.
Listing 5.6 Anfordern von Hauptspeicher mit malloc()
#include <stdlib.h>
int main() {
char* puffer; // Variable deklarieren
puffer = malloc(4096); // 4 KB = 4096 Bytes
// anfordern
// Nun kann der Speicherbereich benutzt werden
free(puffer); // Speicherbereich
// wieder freigeben
// Jeder Zugriff auf den Speicherbereich der
// Variablen 'puffer', der nach dem Freigeben
// erfolgt, führt zu einem Speicherzugriffsfehler.
return 0; // Programm beenden
}
Das obige Beispiel in der Programmiersprache C zeigt sehr deutlich, wie sich der Programmierer bei dieser Sprache selbst um die Verwaltung des Speichers kümmern kann. Der Speicher wird nicht nur per malloc() angefordert, sondern muss auch mit einem Aufruf von free() wieder freigegeben werden.
[»]Unter Linux sind malloc() und free() keine Syscalls, sondern »nur« Funktionen der Standard-C-Library. Der zugehörige Syscall, über den der Kernel Speicher reserviert oder freigibt, heisst brk(). Laut Manpage sollte brk() aber nicht direkt verwendet werden, stattdessen sind malloc() und free() zu benutzen.
Andere Programmiersprachen
Andere Programmiersprachen verstecken diese Syscalls teilweise vor dem Programmierer. Damit ist das Programmieren zwar einfacher, aber nicht unbedingt flexibler. In Java zum Beispiel sieht die Anforderung von neuem Speicher ganz anders aus, auch wenn intern natürlich dieselben Syscalls genutzt werden.
[zB]Neue Objekte werden bei solchen Sprachen mit einem Aufruf von new angelegt. Natürlich reserviert dieser Aufruf auch den für das Objekt nötigen Speicherplatz, allerdings ohne dass sich der Programmierer näher damit auseinandersetzen muss, wie viel das ist. Einen free()-ähnlichen Aufruf sucht man dagegen vergeblich. Nicht mehr benutzter Speicher wird nämlich von der das Java-Programm ausführenden virtuellen Maschine, also dem Programm, das den maschinenunabhängigen Bytecode interpretiert, durch eine Garbage Collection wieder freigegeben: Ein »Müllsammler« durchsucht den gesamten Speicherbereich der Applikation nach nicht mehr genutzten Referenzen und löscht diese. Diese Garbage Collection war früher auf etwas langsameren Systemen die Ursache dafür, dass bei etwas umfangreicheren Java-Programmen das System in regelmäßigen Abständen stehen blieb. Mittlerweile sind die Systeme aber so leistungsfähig und die Algorithmen so ausgereift, dass dieser Performancenachteil nicht mehr ins Gewicht fällt.
5.2.3 Ressourcenverwaltung
Betrachtet man die letzten Beispiele, so leuchtet auch die Aufgabe der Ressourcenverwaltung ein. Der Begriff Ressource wird dabei im weitesten Sinne verstanden: Der Prozessor zählt nämlich genauso als Ressource wie die durch ihn realisierte Rechenzeit. Zu den verwalteten Ressourcen gehören also darüber hinaus:
- Prozessor (bzw. Rechenleistung und Timer)
- Speicher (bzw. RAM und Festplatte)
- Maus
- Bildschirm
- Drucker
- Netzwerkkarten
Spooling
Warum und inwiefern eine solche Verwaltung nötig ist, zeigt das klassische Druckerbeispiel: Stellen Sie sich vor, zwei Programme versuchten, parallel zu drucken. Hätten beide direkten Zugriff auf den Drucker, wären wahrscheinlich beide Ausgaben auf einem Ausdruck gemischt – das genaue Gegenteil von dem, was erreicht werden sollte. Stattdessen wird das Betriebssystem oder (wie im Falle von Linux und BSD) ein spezieller Dienst die Druckwünsche entgegennehmen und erst einmal auf der Festplatte zwischenspeichern. Dieser Dienst könnte dann exklusiv auf den Drucker zugreifen und einen Auftrag nach dem anderen abarbeiten, ohne dass es zu Problemen und Konflikten kommt.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.