Betriebssysteme - Einleitung

Betriebssysteme - Einleitung ... alois.schuette@h-da.de 

Betriebssysteme - Einleitung 

... alois.schuette@h-da.de 

Alois Schütte 

23. Oktober 2013 

1 / 97


Inhaltsverzeichnis 

In diesem Teil wird in die Thematik der Betriebssysteme eingeführt. 

1 Überblick 

2 Was ist ein Betriebssystem 

3 Historische Betrachtung 

4 Grundlegende Konzepte 

5 Systemaufrufe 

6 Betriebssystemstrukturen 

2 / 97


Überblick 

Überblick 

Software kann grob in zwei Arten eingeteilt werden: 

• Systemsoftware, die den Rechner selbst steuert und 

• Anwenderprogramme, die die Aufgaben der Anwender lösen. 

Das wichtigste Systemprogramm ist das Betriebssystem, es 

• kontrolliert die Ressourcen des Rechners und 

• ist Basis für die Entwicklung der Anwenderprogramme. 

3 / 97


Überblick 

Ein moderner Rechner besteht u.a. aus den Komponenten: 

• ein oder mehrere Prozessoren, 

• Hauptspeicher, 

• Taktgeneratoren, 

• Datenendgeräte, 

• Plattenlaufwerke, 

• Netzwerkkomponenten und 

• DFÜ Einrichtungen. 

Insgesamt also eine komplexe Hardware. 

4 / 97


Überblick 

Schichtenmodell 

• Ziel der Systemprogrammierung 

ist es, die Anwender vor der 

Komplexität der Hardware zu 

bewahren. 

• Um der Komplexität Herr zu 

werden, kann man Rechner in 

Schichten einteilen. 

• Das Betriebssystem ist eine 

Softwareschicht oberhalb der 

Hardware, bedient alle Teile des 

Systems und stellt dem 

Anwender eine virtuelle 

Maschine bereit, die einfach zu 

verstehen und zu bedienen ist. 

SAP Office ... 

Compiler Editoren Shells 

Betriebssystem 

Maschinensprache 

Mikroprogrammierung 

physikalische Geräte 

Systemprogramme 

Anwendungsprogramme 

Hardware 

5 / 97


Was ist ein Betriebssystem 

Betriebssystem als virtuelle Maschine 

• Rechner sind auf Maschinenebene umständlich zu programmieren. 

Soll ein Text auf Diskette gespeichert werden, muss man auf 

Maschinenebene die Struktur des Speichermediums (Spuren, 

Sektoren, ...) und die Maschinenbefehle zum Positionieren des 

Lese/Schreibkopfes kennen. 

• Ein Anwendungsprogrammierer soll sich mit solchen Details der 

physischen Geräte nicht kümmern. Er erwartet von einem 

Betriebssystem eine ” 

virtuelle Maschine“, auf der er dateiorientiert 

Lesen und Schreiben kann. 

6 / 97


Was ist ein Betriebssystem 

Betriebssystem als Ressourcenverwalter 

• Heutige Rechner sind leistungsfähig genug, um mehreren 

Benutzern Zugriff auf angeschlossene Drucker, Modems oder 

Prozessoren zu geben. 

Damit unterschiedliche Benutzer die selben Ressourcen 

gleichzeitig“ nutzen können, sind Verwaltungsaufgaben 

” 

erforderlich. 

• Ein Betriebssystem übernimmt die Verwaltung der unterschiedlichen 

an den Rechner angeschlossenen Geräte und der Bestandteile des 

Rechners selbst, wie Hauptspeicher oder Prozessoren. 

7 / 97


Historische Betrachtung 


1 Überblick 



Erste Generation: Röhrenrechner (1945-1955) 

Zweite Generation: Transistoren und Stapelsysteme (1955-1965) 

Dritte Generation: Multiprogrammierung (1965-1980) 

Vierte Generation: Personalcomputer (seit 1980) 

Netzwerk-Betriebssysteme und Verteilte Systeme 




8 / 97



analytical engine 

Der erste digitale Rechner wurde von dem 

englischen Mathematiker Charles Babbage (1792- 

1871) entworfen. 

• Seine ” 

analytical engine“ funktionierte nie, 

denn ihr rein mechanischer Aufbau ließen die 

Fertigung mit der erforderlichen Präzision 

damals nicht zu. 

• Programmiert wurde in Assembler; es war 

die erste Turing-vollständige 

Programmiersprache. 

• Dennoch, dieser Rechner wäre ohne 

Betriebssystem ausgekommen. 

Abbildung : analytical engine 

9 / 97





Der erste brauchbare digitale Rechner wurde im zweiten Weltkrieg 

entwickelt, die trotz ihre Größe (ein ganzer Raum voll mit Rohren, 

Kühlungen und E/A Geräten) weniger Rechenleistung vollbrachten als ein 

heutiger moderner PDA. 

• Diese Röhrenrechner wurden von wenigen 

Ingenieuren konzipiert, gebaut, programmiert, 

betrieben und gewartet. Die Programmierung 

erfolgte im Binärcode. Programmiersprachen 

und Betriebssysteme waren noch 

unbekannt. Die ersten Programme waren 

Berechnungen von Sinus- und Kosinustabellen. 

• Anfang der fünfziger Jahre begann man, die 

Programme im Binärcode auf Lochkarten zu 

schreiben, damit sie wieder verwendbar waren. 

Abbildung : Zuse Z22 

10 / 97




Zweite Generation: Transistoren und Stapelsysteme 

(1955-1965) 

Die Erfindung des Transistors führte dazu, dass Rechner zuverlässiger 

arbeiteten. Ab diesem Zeitpunkt wurde zwischen Entwicklern, Herstellern, 

Betreibern und Wartungspersonal unterschieden. 

• Die Maschinen wurden in gesicherten Räumen 

aufgestellt, die von Bedienern (operator) betreut 

wurden. 

• Wenn ein Rechenauftrag (job) ausgeführt werden 

sollte, musste ein Programmierer die Befehlsfolge 

auf Lochkarten stanzen und dem Operator 

übergeben. Der legte die Lochkarten in den 

Kartenleser und startete den Übersetzungslauf 

und anschliessend das Programm. Das Ergebnis 

(Ausdruck auf Papier) brachte der Operator in 

den Ausgaberaum, wo der Programmierer das 

Resultat abholen konnte. 

11 / 97




• Die hohen Investitionskosten zwangen die Entwickler dazu, nach 

effizienteren Wegen zu suchen. Der Stapelbetrieb (batch system) 

sollte die Systeme besser auslasten. Zuerst wurden die Aufträge im 

Eingaberaum gesammelt und dort auf einem Magnetband mit einem 

kleineren Rechner übertragen, der teilweise auch die Übersetzung 

(Fortran-Maschinenkode) vornahm. Diese Prozedur wurde wiederholt 

(etwa eine Stunde) bis genügend viele Aufträge auf dem 

Magnetband waren. 

• Das erzeugte Eingabeband wurde dann zum eigentlichen Rechner 

gebracht. Dort wurde ein spezielles Programm gestartet (eigentlich 

der Vorfahre eines Betriebssystems), das das Eingabeband einlas, die 

Programme ausführte und das Ergebnis auf ein Ausgabeband 

schrieb. Der Operator brachte das Band dann zu einem weiteren 

Rechner, der die Ergebnisse ausdruckte. 

12 / 97




• Diese Abarbeitungsmethodik von 

Kontrollkarten war der Vorgänger heutiger 

Kommandointerpreter (Shells). 

• Großrechner der zweiten Generation wurden 

weitgehend in Forschungseinrichtungen, etwa 

zur Lösung von Differentialgleichungen 

eingesetzt. Programmiert wurde in Fortran 

oder Assembler. In Banken und 

Versicherungen begann die EDV eine wichtige 

Rolle zu spielen – der ” 

closed job“ Betrieb 

wurde etabliert. 

• Typische Betriebssysteme waren FMS (Fortran 

Monitor System) und IBSYS, das IBM 

Betriebssystem des Großrechners 7094. 

Abbildung : Lochkartenstapel 

13 / 97





Anfang der sechziger Jahre hatten die meisten Computerhersteller zwei 

unterschiedliche und gegenseitig inkompatible Produktlinien: 

• wortorientierte Grossrechner für den 

technisch-wissenschaftlichen Bereich und 

• zeichenorientierte Rechner für den 

kommerziellen Bereich, die hauptsächlich 

für Bandsortierungen und zum Ausdrucken 

(Auszüge, Fälligkeitslisten) bei Banken. 

• IBM versuchte daraufhin mit einem 

einheitlichen Konzept, dem System /360, 

beide Anwendungsbereiche durch eine 

Systemfamilie mit softwarekompatiblen 

Abbildung : IBM 360 

Rechnern abzudecken. 

Dieses Konzept war sehr erfolgreich. Nachfolger dieser Familie (z.B. 370, 

3090) sind z.T. noch heute bei Banken im Einsatz. 

14 / 97




Der Vorteil, ein Betriebssystem für alle Bereiche und Programme, das auf 

allen Rechnern der Familie lauffähig war, erwies sich im Laufe der Zeit als 

die größte Schachstelle: 

es entstand ein sehr großes, kaum mehr zu wartendes 

Betriebssystem. 

Die wichtigsten Schlüsseltechniken der Betriebssysteme dieser 

Generation waren/sind: 

1 Mehrprogrammbetrieb, 

2 Spooling und 

3 Timesharing Betrieb. 

15 / 97




Mehrprogrammbetrieb 

Der Mehrprogrammbetrieb (multiprogramming) wurde entwickelt, 

nachdem festgestellt wurde, dass gerade bei E/A intensiven 

Anwendungen die CPU die meiste Zeit nicht ausgelastet war. Z.B. 

wartete die CPU auf das Terminieren eines Bandkopierens, bevor sie den 

nächsten Auf- trag ausführte. 

Job5 

• Die Lösung bestand in der Aufteilung 

des Hauptspeichers in 

Speicherabschnitte auf Hardwareebene 

(jeweils mit Auftrag und 

Schutzmechanismen), die sicherstellen, 

dass Aufträge sich nicht gegenseitig 

beeinträchtigen. 

Job4 

Job3 

Job2 

Job 1 

Betriebssystem 

Hauptspeicher 

Abbildung : Mehrprogrammbetrieb mit 

5 Jobs im Speicher 

16 / 97




Spooling 

Spooling (Simultaneous Peripheral Operation On Line) bezeichnet 

ursprünglich die unmittelbare Zwischenspeicherung von Aufträgen, 

die vom Kartenleser direkt auf Platten übertragen wurden. 

• Wenn ein Auftrag terminierte, konnte das Betriebssystem einen 

neuen Auftrag sofort in den freien Speicherbereich laden und 

bearbeiten. 

• Heute wird diese Technik noch im Bereich Ausgabe angewendet 

(Drucker Spooling). 

Die Rechner der dritten Generation waren zwar sehr leistungsfähig, sowohl 

im kaufmännischen als auch im technisch wissenschaftlichen Bereich. 

Die Verarbeitung war aber hauptsächlich Stapelverarbeitung: ein Fehler, 

der in einer Ausgabe (Liste) bemerkt wird, muss korrigiert werden und 

ein neuer Compile Auftrag muss eingeplant werden, dann erst kann die 

korrigierte Version in einem neuen Auftrag laufen. 

17 / 97




Dialogsysteme 

Der Wunsch nach schnelleren Reaktions- und Antwortzeiten brachte 

Dialogsystem (timesharing) hervor: jeder Benutzer ist online mit dem 

Rechner über ein eigenes Terminal verbunden. 

MULTICS Das MIT, Bell Labs und General Electric wollten eine 

Maschine entwickeln, mit der gleichzeitig mehrere 

hundert Benutzer arbeiten können sollten. Vorbild war 

das elektrische Versorgungssystem: ein elektrisches Gerät 

wird einfach an eine Steckdose angeschlossen. Obwohl das 

Projekt MULTICS (MULTiplexed Information and 

Computing Service) nie abgeschlossen wurde, sind aus ihm 

viele wichtige Ideen in die Informatik eingeflossen und 

Nachfolgeprojekte stark beeinflusst worden. 

18 / 97




Minicomputer 

• Ein weiterer wesentlicher Faktor der 

Entwicklung der Rechner der 3. Generation 

bestand im Wachstum der Minicomputer, 

beginnend mit der DEC PDP-1 im Jahre 1961. 

Sie verfügte über 4k 18 Bit Worte, kostete nur 

120.000 USD (ca. 5% einer IBM 7094) und 

war im Bereich numerische Berechnungen mit 

einer IBM 7094 vergleichbar, aber zu IBM 

inkompatibel. 

• Die leistungsstärksten PDP Rechner (PDP-11) 

waren noch Ende der 80er Jahre in vielen 

Forschungsinstituten zu finden. 

Abbildung : Ken Thompson 

und Dennis Ritchie 1972 vor 

einer PDP-11 

19 / 97




UNICS, C 

• Ein Mitarbeiter des MULTICS Projektes bei Bell Labs, Ken 

Thompson, schrieb eine abgemagerte Version als 

Einbenutzersystem. Brian Kernighan bezeichnete dieses System als 

UNICS (UNiplexed Information and Computing Service), später 

wurde es dann UNIX genannt. 

• Ein anderer Informatiker bei Bell, Dennis Ritchi entwickelte die 

Programmiersprache C, um damit Unix neu zu schreiben. Ziel war 

es, ein Betriebssystem für den Mehrbenutzerbetrieb zu realisieren, 

das leicht auf unterschiedliche Rechner portierbar war. Bell Labs 

vergab Unix Lizenzen kostenlos an Hochschulen. Dadurch wurde es 

auf viele Plattformen portiert. Unix und die freie Version Linux ist 

das Betriebssystem, das auf den meisten Plattformen portiert wurde. 

Die Vorlesung wird sich stark an Unix orientieren, um Konzepte von 

Betriebssystemen zu erklären. 

20 / 97





Durch Fortschritte in der Entwicklung hochintegrierter Schaltkreise 

konnten Rechner konstruiert werden, die auch für Einzelpersonen 

erschwinglich waren. 

Der PC wurde mit Betriebssystemen und Oberflächen ausgestattet, die es 

auch ” 

Normalbenutzern“ ermöglichten, damit zu arbeiten. 

Zwei Betriebssysteme hatten sich für PCs durchgesetzt: 

• MS-DOS von Microsoft für Intel-basierte Hardware und 

• Unix für Systeme, die auf Motorolas 68000er Familie beruhten. 

MS-DOS entwickelte sich bezogen auf die Funktionalität immer mehr in 

Richtung Unix (Microsoft war zu dieser Zeit der führende Unix Lieferant 

[XENIX]). 

21 / 97





Seit Mitte der 80er Jahre wurden Rechner mehr und mehr vernetzt. 

Dadurch wurden Betriebssystemkonzepte erforderlich, die mit der 

Problematik 

• des Datenaustausches, 

• dem Verteilen von Aufgaben und 

• der Kommunikation zwischen Prozessen, 

die auf unterschiedliche Knoten im Netz ablaufen, erforderlich. 

22 / 97




Netzwerkbetriebssysteme 

Netzwerkbetriebssysteme erlauben einem Benutzer, Daten von anderen 

bekannten Rechnern zu verwenden und sich auf anderen bekannten 

Rechnern anzumelden. 

• Dabei können die verschiedenen Rechner unterschiedliche 

Betriebssysteme haben. Die Transparenz beim Kopieren von Daten 

geschieht durch die Verwendung von Standardprotokollen (z.B. ftp). 

• Die Netzwerkbetriebssysteme unterscheiden sich nicht von den 

Einprozessor Betriebssystemen; auf unterster Ebene ist lediglich eine 

Schicht, die über einen Netzwerkkontroller auf Netzressourcen 

zugreift. 

• Weiterhin sind Programme erforderlich, um Remoterechner 

ansprechen zu können (telnet, rsh, ssh, sftp, scp). 

23 / 97




Verteilte Betriebssysteme 

Verteilte Betriebssysteme spiegeln dem Benutzer ein Einprozessorsystem 

vor: 

der Benutzer weiß nicht, auf welchem Knoten im verteilten 

System sein Programm abläuft. 

• Auf der Betriebssystemseite sind (im Gegensatz zu 

Netzwerkbetriebssystemen) hier neue komplexere Algorithmen 

erforderlich, die die Verteilung der Programmstücke auf verschiedene 

Prozessoren vornehmen, um viel paralleles Arbeiten zu ermöglichen. 

• Die Problematik resultiert im Prinzip daraus, dass es keine zentrale 

Haltung von Zustandsinformation gibt. Der Entwurf eines verteilten 

Systems hat darüber hinaus zum Ziel, die Ausfallsicherheit und 

Fehlertoleranz des Gesamtsystems zu erhöhen: der Ausfall von 

Komponenten soll ohne Beeinträchtigung der Funktionalität 

gewährleistet werden können. 

Diese Verteilten Betriebssysteme werden hier nicht behandelt ! 

24 / 97


Grundlegende Konzepte 


1 Überblick 




Prozesse 

Dateien 

Kommandointerpreter 



25 / 97



Prozesse 

Prozesse 

Ein Prozess ist ein Programm, das sich in der Ausführung befindet. 

Während ein Programm nur einmal auf der Festplatte gespeichert ist, 

dann dieses Programm mehrmals aufgerufen sein, also können von einem 

Programm mehrere Prozesse existieren. 

Ein Prozess besteht aus: 

• dem Programmcode, 

• den Programmdaten, 

• dem Programmstack, 

• dem Befehlszähler, 

• dem Stackzeiger und 

• Speicherinformationen, die zum Ablauf erforderlich sind. 

26 / 97



Prozesse 

Der Prozessbegriff orientiert sich an den Erfordernissen von Timesharing 

Systemen, d.h. 

das Betriebssystem muss periodisch entscheiden, 

• ob der aktuelle Prozess weiterlaufen darf, oder 

• ob seine Zeitscheibe schon abgelaufen ist, er also suspendiert werden 

muss, um einem neuen Prozess die CPU zuteilen zu können. 

Wird ein Prozess suspendiert, so muss er bei der Reaktivierung im selben 

Zustand weitermachen können. 

Deshalb ist es erforderlich, sich den zuletzt ausgeführten Befehl vor der 

Suspendierung mit allen Umgebungsmerkmalen zu merken, z.B. die 

aktuell geöffneten Dateien, pro Datei den Stand des Lese/Schreib-Kopfes 

usw. 

27 / 97



Prozesse 

Prozesstabelle 

Diese Informationen werden i.A. in einer so genannten Prozesstabelle 

gespeichert. Sie besteht aus einem Feld von Strukturen, die die o.a. 

Informationen pro suspendiertem Prozess enthält. Damit besteht ein 

suspendierter Prozess aus: 

• seinem Prozessadressraum 

(dem Speicher in dem Programm und Daten liegen) und 

• seinem Eintrag in der Prozesstabelle. 

28 / 97



Prozesse 

Systemaufrufe 

Systemaufrufe zur Prozessverwaltung sind u.a. dafür verantwortlich, dass 

• Prozesse erzeugt und terminiert werden, 

• Speicher für einen Prozess angefordert und freigegeben wird, 

• ein Prozess sich mit anderen ” 

unterhalten kann“ und 

• die Ablaufumgebung von Prozessen definiert (Größe des Speichers, 

Anzahl max. geöffneter Dateien, ...) wird. 

29 / 97



Prozesse 

Prozessbaum 

• Wenn ein Benutzer mit dem Betriebssystem 

arbeitet, so werden seine Anfragen von der Shell 

bearbeitet. 

• Dies ist ein Prozess, der die Kommandos des 

Benutzers liest, interpretiert und ausführt. 

• Nehmen wir an, der Benutzer gibt ein Kommando 

zum Suchen einer Datei ein. Dann muss die Shell 

einen Prozess erzeugen, ihm den Code des 

Such-Kommandos überlagern, ihn ausführen und 

dann beenden. 

• Durch das Erzeugen von Prozessen (Kindern), 

ausgehend von einem Erzeuger-Prozess (Vater), 

entsteht eine Baumstruktur von Prozessen. 

Abbildung : 

Prozessbaum 

30 / 97



Dateien 

Dateien 

• Dateien werden in Betriebssystem 

systematisch auf Plattenbereiche verteilt. 

• Systemaufrufe existieren zum Öffnen, Lesen, 

Schreiben und Schließen einer Datei. 

• Dateien in Linux werden organisiert, indem 

man Verzeichnisse anlegen kann. Ein 

Verzeichnis ist ein Katalog mit Inhalten, die 

aus Dateien und selbst wieder Verzeichnissen 

bestehen können. Somit hat auch das 

Dateisystem eine baumartige Struktur. 

• Wenn ein Benutzer sich in Linux anmeldet, so 

ist er automatisch in seinem Heimatverzeichnis 

(home directory). Die Daten kann er sich dort 

selbst organisieren. 

Abbildung : Dateibaum 

31 / 97



Dateien 

Zugriffsrechte 

Der Zugriff auf Dateien ist in Linux durch einen sechsstelligen binären 

Zugriffscode, der jeder Datei zugeordnet ist, geschützt. 

• Dieser Code besteht aus jeweils 3 Bit für den Eigentümer, die 

Gruppe zu der der Eigentümer gehört und für alle anderen. 

• Rechte können pro Kategorie vergeben werden: Lesen (r), Schreiben 

(w) und Ausführen (x). 

• Somit hat eine Datei, die nur der Benutzer Lesen, Schreiben und 

Ausführen darf, die Zugriffsmaske " 

rwx------ " 

. 

• Für Verzeichnisse bedeutet das x-Bit, dass im Katalog gesucht 

werden darf. 

(sticky bit und set user id bit später) 

32 / 97



Dateien 

mounten 

Wenn ein Betriebssystem hochgefahren wird, so wird i.A. zuerst das 

Dateisystem, auf dem sich das Betriebssystem selbst befindet, verfügbar 

gemacht. Es befindet sich normalerweise auf der Festplatte. 

• Daneben existieren auswechselbare 

Speichermedien z.B. 

USB-Laufwerke oder CD 

Laufwerke. 

• Auf solchen Medien kann man ein 

auswechselbares Dateisystem 

(mounted file system) anlegen. Es 

wird in das Hauptdateisystem 

eingehängt und ist ab diesem 

Zeitpunkt ” 

normal“ über den 

Pfadnamen erreichbar. 

Abbildung : mounten 

33 / 97





Das Betriebssystem ist der für die Ausführung von Systemaufrufen 

verantwortliche Teil der Systemsoftware. Wie im Schichtenmodell gezeigt, 

ist der Kommandointerpreter nicht Bestandteil des Betriebssystems. 

• Jedes Kommando, das der Benutzer 

absendet, bewirkt, dass die Shell einen 

Kindprozess erzeugt, der das 

Kommando ausführt. 

• Die Shell wartet, bis der Kindprozess 

terminiert ist. 

• Dann wird wieder ein Prompt 

geschrieben. 

• Soll ein Programm im Hintergrund 

ablaufen, so wird das Kommando mit 

dem Zeichen ’&’ abgeschlossen. 

34 / 97


Systemaufrufe 

Systemaufrufe 

1 Überblick 





Prozessverwaltung 

Signale 

Dateiverwaltung 

Katalogverwaltung 

Schutzmechanismen 

Zeitverwaltung 

Ablaufumgebung von Prozessen 

35 / 97


Systemaufrufe 

Systemaufrufe 

Die vorgestellten Systemaufrufe sind an der Implementierung in Unix 

orientiert. In anderen Betriebssystemen sind die Umsetzungen zwar 

teilweise anders, das Prinzip ist aber das gleiche. 

• Systemaufrufe bilden die Schnittstelle zur Hardware, auf dem das 

Betriebssystem abläuft. 

• Deshalb sind grosse Teile eines Systemaufrufs in Assembler 

programmiert. 

• Um sie für Programmierer nutzbar zu machen, wird oft eine 

C-Bibliothek bereitgestellt. 

• Systemaufruf zum Lesen einer Datei ist ” 

read“. 

count = read(file, buffer, nbytes); 

Mit drei Parametern von ” 

read“ wird beschrieben, welche Datei 

gelesen werden soll, wohin die Leseoperation das Ergebnis ablegen 

soll und wieviele Bytes aus der Datei gelesen werden sollen. 

36 / 97


Systemaufrufe 

Beispiel 

simpleCat.c 

1 # define BUFSIZE 512 

2 int main (){ 

3 char buf [ BUFSIZE ]; 

4 int n; 

5 while ((n = read (0 , buf , BUFSIZE )) > 0)


Systemaufrufe 



Ein Prozess besitzt einen Adressraum, in dem er abläuft. Der 

Prozessraum ist in mehrere Teile (Segmente) aufgeteilt. 

• Der Programmcode befindet sich im 

Textsegment. 

• Im Datensegment sind globale Objekte 

abgelegt, 

• dann folgt der Heap für dynamische 

Objekte. 

• Der Stack ist zur Speicherung lokaler 

Objekte und für Rücksprungadressen 

bei Rekursionen nötig. 

• Stack und Heap wachsen aufeinander 

zu. 

Stack 

Heap 

Daten 

Textsegment 

FFFF 

0000 

38 / 97


Systemaufrufe 


fork 

Ein Prozess wird erzeugt, in dem ein Eltern Prozess durch den 

Systemaufruf ” 

fork“ einen Kind Prozess erzeugt. 

• Der Aufruf erzeugt eine exakte Kopie 

des Originalprozesses (Kind=Clone des 

Vaters), einschließlich aller 

Dateideskriptoren, Register usw. 

Stack 

CC00 

Stack 

DD00 

• Nach dem fork werden beide Prozesse 

unterschiedliche Aktivitäten 

übernehmen. 

• Zum Zeitpunkt des fork haben alle 

Variablen die gleichen Werte, nach 

dem fork wirken sich Änderungen der 

Variablen nur noch im jeweiligen 

Prozess aus. 

Heap 

Daten 

pid= 

fork() 

Vater 

AA01 

Heap 

Daten 

pid= 

fork() 

Kind 

CC01 

39 / 97


Systemaufrufe 


fork 

Der fork Aufruf gibt einen Wert zurück, durch den im Programm 

unterschieden werden kann, ob der Code des Kindes oder des Vaters 

gemeint ist. 

0 ist der Kindprozess, 

>0 der Wert ist die 

Prozessidentifikation (pid) 

des Kindprozesses für den 

Eltern Prozess. 


Systemaufrufe 


Beispiel 

fork.c 

1 # include 


3 int childPid ; 

4 if (( childPid = fork ()) == -1) {


Systemaufrufe 


In welcher Reihenfolge erscheinen die Ausgaben ? 

42 / 97


Systemaufrufe 

Shell 


Ein reales Beispiel, bei dem ein Prozess erzeugt wird, ist die Shell. 

• Für jedes Kommando, das aus der 

Shell heraus ausgeführt wird, wird 

von der Shell ein eigener Prozess 

erzeugt. 

• Dabei dupliziert sich die Shell 

durch fork. 

• Im Kind (subshell) wird der Shell 

Code mit dem Code des 

auszuführenden Kommandos 

überlagert (exec). 

• Der Vater wartet (wait) bis der so 

erzeugte Kind-Prozess terminiert 

(exit). 

Somit kann in der Umgebung des Kindprozesses, das echo Kommando 

ausgeführt werden. 

43 / 97


Systemaufrufe 


Shell-Programmgerüst 

1 void read_command ( char *com , char ** par ){ 

2 fprintf ( stdout , "$ "); 

3 ..... 

4 return ; 

5 } 



9 int status ; 

10 char command [20]; 

11 char * parameters [60]; 

12 while (1) { 

13 read_command ( command , parameters ); 

14 if (( childPid = fork ()) == -1) {


Systemaufrufe 


execvp 

Der execvp-Systemaufruf bewirkt, dass das Textsegment des Prozesses 

mit dem Kode des auszuführenden Programms überlagert wird. 

• Der erste Parameter ist das 

auszuführende Programm. 

• Der zweite Parameter ist ein 

Array mit Zeigern auf das 

auszuführende Programm und 

die Programmargumente. 

• Dabei muss der letzte Eintrag 

des Arrays NULL sein. 

parameters 

echo 

Hallo 

Jenni 

NULL 

execvp("echo", "Hallo", Jenni") 

Stack 

Heap 

Daten 

Kode von echo 

Kind 

DD00 

CC01 

Abbildung : execvp 

45 / 97


Systemaufrufe 


exit - wait 

Mittels wait und exit können Vater und Kind ’kommunizieren’. 

• ” 

exit“ hat einen Parameter, den so genannten Exitstatus. 

• Dies ist ein Integerwert zwischen 0 und 255. 

• Konvention in Unix ist, dass ein Exitstatus von Null bedeutet, dass 

die Aktion erfolgreich ausgeführt werden konnte. Jeder andere Wert 

wird als Fehler angesehen. 

• Dieser Status wird dem Elternprozess in der Variablen ” 

status“ des 

wait Aufrufs mitgegeben. 

Soll z.B. eine Kommunikation zwischen Kind und Eltern stattfinden, so 

kann das Kind z.B. durch 

exit(4); 

dem Elternprozess die Nachricht ’4’ übergeben. 

Der Elternprozess wird durch 

child-pid = wait(&status); 

dann die Information in der Variablen status sehen. 

46 / 97


Systemaufrufe 


Im Wert von Status sind unterschiedliche Informationen kodiert. Neben 

dem exit-Wert des Kindes, sind Informationen über die Terminierung des 

Kindes abgelegt. Um diese Informationen auszulesen existieren C-Macros. 

Macro 

WIFEXITED(status) 

WIFSGNALES(status) 

WIFSTOPPED(status) 

Beschreibung 

true, wenn status vom Kind gesetzt und das Kind 

normal beendet wurde. Dann kann man durch WE- 

XITSTATUS(status) die niederwertigen 8 Bit auslesen, 

die den Exit-Wert des Kindes beinhalten. 


abnormal beendet wurde, durch signal. Dann kann 

man durch WTERMSIG(status) die Signalnummer, 

die das Kind beendet hat, abfragen. 


gerade gestopped wurde. Dann kann man durch 

WSTOPSIG(status) die Signalnummer, die das Kind 

gestopped hat, abfragen. 

Der Aufruf von wait() bewirkt, dass der Vaterprozess blockiert, bis irgend 

ein Kinder beendet sind (waitpid später). 

47 / 97


Systemaufrufe 


Beispiel I 

status.c 

1 # include 

2 # include 

3 main () 

4 { 



7 if (( childPid = fork ()) == -1) { 

8 fprintf ( stderr ," can 't fork \n"); 

9 exit (1); 

10 } else if ( childPid == 0) { /* child process */ 

11 fprintf ( stdout , " child : exit 4\n"); 

12 sleep (20);


Systemaufrufe 


Beispiel II 

status.c 

23 WEXITSTATUS ( status ) ); 

24 } else if ( WIFSIGNALED ( status )) { 

25 fprintf ( stdout , " parent : abnormal term . of child , status %d\n", 


27 fprintf ( stdout , " parent : abnormal term . of child , signal number %d\n" 

28 WTERMSIG ( status ) ); 

29 } else if ( WIFSTOPPED ( status )) { 

30 fprintf ( stdout , " parent : child stopped , status %d\n", 


32 fprintf ( stdout , " parent : child stopped , signal number %d\n", 

33 WSTOPSIG ( status ) ); 

34 } 

35 exit (0); 

36 } 

37 } 

> ulab 

49 / 97


Systemaufrufe 


Hörsaalübung 

Welche Ausgabe erzeugt das u.a. Programm? 

fork.c 

1 # include 

2 # include < unistd .h> // wg. getpid 

3 int x = 0; 

4 int main () { 

5 fork (); 

6 fork (); 

7 fork (); 

8 printf (" pid =%d x=%d\n", getpid () , x ++); 

9 } 

→ ulab 

50 / 97


Systemaufrufe 


waitpid 

Mit wait() kann der Elternprozess nur auf die Beendigung irgend eines 

Kindes warten. 

Soll der Vater hingegen auf die Beendigung eines bestimmten Prozesses 

warten, dann ist waitpid() zu verwenden. 

Mit dem ersten Argument von 

waitpid(pid wpid, int *status, int options) legt man fest, 

worauf gewartet werden soll: 

pid Beschreibung 

-1 auf beliebigen Prozess warten – äquivalent zu wait() 

pid auf die Beendigung von pid warten 

0 auf Beendigung warten, dessen Prozessgruppen-ID gleich 

der Prozessgruppen-ID des aufrufenden Prozesses ist. 

< −1 auf Beendigung warten, dessen Prozessgruppen-ID gleich 

der Prozessgruppen-ID des aufrufenden Prozesses ist. 

51 / 97


Systemaufrufe 


waitpid 

Das dritte Argument ” 

options“ von 

waitpid(pid wpid, int *status, int options) bestimmt das 

Verhalten von waitpid(). Folgende Konstanten können dabei verwendet 

werden 

Konstante 

WNOHANG 

WUNTRACED 

WIFSTOPPED 

Beschreibung 

Der aufrufende Prozess wird nicht blockiert, wenn der 

Prozess ppidnnoch nicht beendet wurde bzw. noch nicht 

im Zombie-Status ist. (waitpid() liefert in diesem Fall 0 

zurück). 

Status des angehaltenen Kindprozesses, der mit pid spezifiziert 

wurde. 

liefert 1 zurück, wenn es sich beim Rückgabewert um die 

PID des angehaltenen Kindprozesses handelt. 

Im folgenden Beispiel wird nicht auf die Terminierung des 1. Kindes 

gewartet, es wird ein zweites Kind erzeugt, auf dessen Beendigung 

gewartet wird. 

52 / 97


Systemaufrufe 


Beispiel I 

waitpid.c 

1 # include < unistd .h> 

2 # include ... 

4 int main ( void ) { 

5 pid_t pid1 , pid2 ; 


7 switch ( pid1 = fork ()) { 

8 case -1: 

9 perror (" fork ()"); 

10 return EXIT_FAILURE ; 

11 case 0: // child 1 

12 printf (" child 1: %d\n", getpid ()); 

13 sleep (10); 

14 printf (" child 1: %d terminated \n", getpid ()); 

15 break ; 

16 default : // parent code 

17 if ( waitpid (pid1 , NULL , WNOHANG ) != 0) {


Systemaufrufe 


Beispiel II 

waitpid.c 

23 perror (" fork ()"); 

24 return EXIT_FAILURE ; 

25 case 0: // child 2 

26 printf (" child 2: %d\n", getpid ()); 

27 sleep (5); 

28 printf (" child 2: %d terminated \n", getpid ()); 

29 break ; 

30 default : // parent code 

31 if ( wait ( NULL ) != pid2 ) {


Systemaufrufe 

Signale 

Signale 

Signale sind das Äquivalent im Bereich Software zu Interrupts im Bereich 

Hardware. 

• Wenn ein Signal zu einem Prozess gesendet wird und der Prozess 

das Signal nicht annimmt, dann wird der Prozess vom 

Betriebssystem automatisch entfernt. 

• Um sich vor diesem Automatismus schützen zu können, kann sich 

ein Prozess durch den Systemaufruf ” 

signal“ auf das Eintreffen von 

Signalen vorbereiten. 

• Dazu muss er eine Signalbehandlungroutine bereitstellen. 

• In einem Betriebssystem gibt es mehrere Signalarten. Die meisten 

Signale werden durch Ereignisse, die von der Hardware ausgelöst 

werden, erzeugt. 

55 / 97


Systemaufrufe 

Signale 

Signale 

Die nachfolgende Tabelle listet die wichtigsten Signalarten auf. 

Nummer Konstante Bedeutung 

1 SIGHUP Hang up, Modemunterbrechung 

2 SIGINT DEL Taste 

3 SIGQUIT Quit Signal von Tastatur 

4 SIGILL Nicht erlaubte Instruktion 

5 SIGTRAP Unterbrechung für Testzwecke 

8 SIGFPE Gleitkommaüberlauf 

9 SIGKILL Abbruch 

10 SIBBUS Busfehler 

11 SIGSEGV Segmentfehler 

12 SIGSYS Ungültige Argumente bei Systemaufruf 

13 SIGPIPE Ausgabe auf Pipe ohne Leser 

14 SIGALARM Alarm 

15 SIGTERM Softwareerzeugtes Endesignal 

16 frei frei 

56 / 97


Systemaufrufe 

Signale 

Beispiel 

Eine Endlosschleife wird auf das Eintreffen vom Signal ” 

SIGINT“, 

ausgelöst durch ” 

CTR-C“ reagieren, indem es einen Text ausgibt. signal.c 

1 # include 

2 # include < signal .h> 

4 void handler ( int ) { 

5 printf (" handler \n"); 

6 return ; 

7 } 


10 signal ( SIGINT , handler ); /* CTR -C handled */ 

11 while (1) { 

12 printf (" main \n"); 

13 sleep (2); 

14 } 

15 } 

Wenn ein Programm so geschrieben ist, dass es alle Signale ignoriert, 

könnte es nie abgebrochen werden. Deshalb gibt es das Signal ” 

SIGKILL“. 

Dieses Signal kann nicht per Signalhandler abgefangen werden. 

→ ulab: kill -9 

57 / 97


Systemaufrufe 

Signale 

alarm 

Im Bereich Echtzeitanwendungen muss ein Betriebssystem in der Lage 

sein, Prozesse nach einer gewissen Zeit zu informieren, dass bestimmte 

Dinge zu erledigen sind. 

Der Systemaufruf ” 

alarm“ hat einen Parameter, der die Anzahl Sekunden 

angibt, nach denen das Signal ” 

SIGALARM“ erzeugt werden soll. 

timer.c 

1 void handler ( int ) { 

2 printf (" Bye \n"); 

3 exit (0); 

4 } 

6 main () { 

7 char str [80]; 

8 signal ( SIGALRM , handler ); ← 

9 while (1) { 

10 alarm (5); /* start timer */ ← 

11 printf ("> "); 

12 fgets (str , 80 , stdin ); 

13 printf ("%s\n", str ); 

14 } 

15 } 

58 / 97


Systemaufrufe 


Dateiverwaltung - create 

Das nachfolgende Beispielprogramm ” 

simpleTouch.c“ demonstriert den 


creat“. Das Programm legt die als Aufrufparameter 

anzugebende Datei mit den Zugriffsrechten ” 

0640“ an. 

simpleTouch.c 

1 # include 

2 main ( int argc , char * argv []) { 

3 int fd; 

4 if ( argc != 2) { 

5 fprintf ( stderr , " usage : %s file \n", argv [0]); 

6 exit (1); 

7 } 

8 if (( fd= creat ( argv [1] ,0640)) < 0) { ← 

9 fprintf ( stderr , " create error \n"); 

10 exit (2); 

11 } 

12 } 

Achtung: wenn die Datei bereits existiert, wird sie überschrieben! 

59 / 97


Systemaufrufe 


open 

Bevor eine Datei bearbeitet werden kann, muss sie geöffnet werden. Dazu 

existiert der Systemaufruf ” 

open“, der neben dem Namen noch die Art 

des Zugriffs (Lesen, Schreiben oder beides) benötigt. 

Das folgende Programm liest die als Parameter anzugebende Datei und 

schreibt den Inhalt auf die Standardausgabe. 

cat.c 


2 main ( int argc , char ** argv ) { 

3 int fd; ← 

4 int n; 


6 if ( argc != 2) { /* check usage */ 

7 fprintf ( stderr , " usage %s file \n", argv [0]); 

8 exit (1); 

9 } 

10 if (( fd= open ( argv [1] , O_RDWR )) < 0) { /* open file */ ← 

11 fprintf ( stderr , " open error \n"); 

12 exit (2); 

13 } 

14 while ((n = read (fd , buf , BUFSIZE )) > 0) /* read and write file */ 

15 write (1 , buf , n); ← 

16 } 

Achtung: wenn die Datei bereits existiert, wird sie uberschrieben! 

60 / 97


Systemaufrufe 


Wahlfreier Zugriff - fseek 

Der wahlfreie Zugriff auf Dateien wird durch den Systemaufruf lseek“ ” 

realisiert. 

fseek(file, no-bytes, start); hat drei Parameter: 

1 einen Filedescriptor, der die zu bearbeitende Datei definiert, 

2 den Offset , der die Position des Lese/Schreibkopfes in Byte relativ 

zum Ausgangspunkt definiert und 

3 den Ausgangspunkt für die Positionierung des Lese/Schreibkopfes 

• SEEK SET=Dateianfang 

• SEEK END=Dateiende 

• SEEK CUR=aktuelle Position 

Damit kann man ein Programm, das eine Datei (angefangen am 

Dateiende, d.h. rekursiv) liest einfach programmieren. 

61 / 97


Systemaufrufe 

fseek 

revCat.c 



2 int fd; 

3 int pos ; 

4 char buf [1]; 


7 fprintf ( stderr , " usage %s file \n", argv [0]); 

8 exit (1); 

9 } 

10 if (( fd= open ( argv [1] , O_RDWR )) < 0) { /* open file */ 

11 fprintf ( stderr , " open error \n"); 

12 exit (2); 

13 } 

14 if (( pos = lseek (fd , -1, SEEK_END )) == -1) { /* pos == # bytes in file */ 

15 fprintf ( stderr , " lssek error \n"); 

16 exit (1); 

17 } 

18 while (pos >=0) { /* read and write file */ 

19 read (fd , buf , 1); 

20 write (1 , buf , 1); 

21 lseek (fd , --pos , SEEK_SET );


Systemaufrufe 


fseek 

Im folgenden Programm ” 

hole.c“ wird der Systemaufruf ” 

lseek“ 

verwendet, um ein Loch in einer Datei zu erzeugen. 

hole.c 


2 int fd; 

3 char buf1 [] = " abcdefghijklmnop "; 

4 char buf2 [] = " ABCDEFGHIJKLMNOP "; 

6 if (( fd= creat (" file . hole " ,0640)) < 0) { 

7 fprintf ( stderr , " create error \n"); exit (1); 

8 } 

9 if (( write (fd , buf1 , 16)) != 16) { /* offset now 16 */ 

10 fprintf ( stderr , " buf1 write error \n"); exit (2); 

11 } 

12 if (( lseek (fd , 32 , SEEK_SET )) == -1) { /* offset now 32 */ ← 

13 fprintf ( stderr , " lseek error \n"); exit (3); 

14 } 

15 if (( write (fd , buf2 , 16)) != 16) { /* offset now 48 */ 

16 fprintf ( stderr , " buf2 write error \n"); 

17 exit (4); 

18 } 

19 exit (0); 

20 } 

63 / 97


Systemaufrufe 


fseek 

Ein Aufruf bewirkt: 

$ hole file . hole 

$ ls -l fil * 

-rw -r----- 1 as users 48 Nov 1 19:11 file . hole 

$ od -c file . hole 

00 a b c d e f g h i j k l m n o p 

20 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 Loch 

40 A B C D E F G H I J K L M N O P 

60 

$ 

64 / 97


Systemaufrufe 


Dateistatus - stat 

Die Informationen über eine Datei, der so genannte Dateistatus, kann 

durch die Systemaufrufe abgefragt werden. 

• ” 

stat“ und ” 

fstat“ liefern Information über Dateien, 

• ” 

lstat“ über Links. 

Alle Aufrufe geben eine Struktur vom Typ ” 

stat“ zurück. 

1 struct stat { 

2 dev_t st_dev ; /* ID of device containing file */ 

3 ino_t st_ino ; /* inode number */ 

4 mode_t st_mode ; /* protection */ 

5 nlink_t st_nlink ; /* number of hard links */ 

6 uid_t st_uid ; /* user ID of owner */ 

7 gid_t st_gid ; /* group ID of owner */ 

8 dev_t st_rdev ; /* device ID (if special file ) */ 

9 off_t st_size ; /* total size , in bytes */ 

10 blksize_t st_blksize ; /* blocksize for file system I/O */ 

11 blkcnt_t st_blocks ; /* number of 512 B blocks allocated */ 

12 time_t st_atime ; /* time of last access */ 

13 time_t st_mtime ; /* time of last modification */ 

14 time_t st_ctime ; /* time of last status change */ 

15 }; 

65 / 97


Systemaufrufe 


Beispiel - lstat 

simpleFile.c 

1 int main ( int argc , char ** argv ) { 

2 int i; 

3 struct stat buf ; 

4 char * ptr ; 


6 fprintf ( stderr , " usage %s file \n", argv [0]); exit (1); 

7 } 

8 if ( lstat ( argv [1] , & buf ) < 0) { /* get file info */ ← 

9 fprintf ( stderr , " lstat error \n"); exit (2); 

10 } 

11 /* print file info */ 

12 if ( S_ISREG ( buf . st_mode )) ptr = " regular "; 

13 else if ( S_ISDIR ( buf . st_mode )) ptr = " directory "; 

14 else if ( S_ISCHR ( buf . st_mode )) ptr = " character special "; 

15 else if ( S_ISBLK ( buf . st_mode )) ptr = " block special "; 

16 else if ( S_ISFIFO ( buf . st_mode )) ptr = " fifo "; 

17 else if ( S_ISLNK ( buf . st_mode )) ptr = " link "; 

18 else ptr = " unknown mode !"; 

19 printf ("%s: %s\n", argv [1] , ptr ); 

20 } 

66 / 97


Systemaufrufe 


Pipes 

Pipes sind ein Kommunikationsmedium, das es erlaubt, dass Prozesse in 

FIFO Manier kommunizieren. Eine Pipe ist dabei eine Pseudodatei, die 

die Kommunikationsdaten temporär beinhaltet. 

• In Unix können durch folgende 

Kommandofolge zwei Dateien sortiert und in 

einer Datei zusammengeführt werden: 

cat file2 file2 | sort 

• Hierbei werden zwei Prozesse erzeugt: der 

erste (cat) schreibt seine Ausgabe in die Pipe, 

der zweite (sort) liest die Standardeingabe aus 

der Pipe. 

cat datei 

sort 

67 / 97


Systemaufrufe 


pipe 

Der Systemaufruf ” 

pipe“ erzeugt eine Pipe und gibt zwei 

Dateideskriptoren zurück, einen zum Lesen und einen zum Schreiben. 

Der Mechanismus wird nun am Beispiel eines Programmes gezeigt, bei 

dem ein Vaterprozess einem Kind Informationen über eine Pipe sendet. 

int p[2]; 

pipe(p); /* p[1]=Schreibende, p[0]=Leseende */ 

68 / 97


Systemaufrufe 


Beispiel - pipe I 

pipe.c 

1 /* Example : Child | Father */ 


3 main () { 

4 int pid , status ; 

5 int p [2]; ← 


7 if ( pipe (p) != 0) {


Systemaufrufe 


Beispiel - pipe II 

pipe.c 

22 sleep (2); /* just to have more time to see it with "ps -el" 

23 } 

24 close (p [1]); 

25 exit (0); 

26 } 

27 default : /* father : read from pipe */ 

28 { int length ; 

29 close (p [1]); /* close write end of pipe */


Systemaufrufe 


named pipes 

Sollen zwei unabhängige Prozesse über eine Pipe kommunizieren, muss 

die Pipe außerhalb des Adressraums der beiden Prozesse abgebildet 

werden. 

Eine named Pipe (FIFO) wird erzeugt durch den Systemaufruf: 

int mknod(char *pathname, int mode, int dev); 

Dabei ist pathname, ein Dateiname von Unix, der Name des FIFO. Das 

Argument mode definiert den Zugriff (read, write mit Rechten für owner, 

group, others). mode wird logisch OR verknüpft mit dem Flag S IFIFO 

(aus < sys/stat.h >), um auszudrücken, dass mknode einen FIFO 

erzeugen soll. dev wird für FIFOs ignoriert (relevant für andere Objekte). 

FIFOs können auch durch das Unix Kommando mknod erzeugt werden: 

/etc/mknod name p 

71 / 97


Systemaufrufe 


named pipe - Beispiel Client/Server cat 

Eine Client-Server Anwendung, bei der ein Client einen Dateinamen von 

stdin einliest und den Namen auf einen Kommunikationskanal schreibt. 

Der Server liest den Dateinamen vom Kommunikationskanal, öffnet die 

Datei, liest den Inhalt und schreibt ihn über einen Kommunikationskanal 

zurück. Der Client erwartet den Inhalt der Datei vom 

Kommunikationskanal (FIFO) und gibt ihn über stdout aus. 

72 / 97


Systemaufrufe 


named pipe - Beispiel Client/Server cat (Server) 

server.c fifo.h 

1 # define MAXBUFF 1024 

2 main () { 

3 int readfd , writefd ; 

4 /* Create the FIFOs , then open them - one for 

5 reading and one for writing . */ 

7 if ( ( mknod ( FIFO1 , S_IFIFO | PERMS , 0) < 0) 

8 && ( errno != EEXIST )) 

9 perror (" can 't create fifo : FIFO1 "); 

10 if ( ( mknod ( FIFO2 , S_IFIFO | PERMS , 0) < 0) 

11 && ( errno != EEXIST )) { 

12 unlink ( FIFO1 ); 

13 perror (" can 't create fifo : FIFO2 "); 

14 } 

15 if ( ( readfd = open ( FIFO1 , 0)) < 0) 

16 perror (" server : can 't open read fifo : FIFO1 "); 

17 if ( ( writefd = open ( FIFO2 , 1)) < 0) 

18 perror (" server : can 't open write fifo : FIFO2 "); 

20 server ( readfd , writefd ); 

21 close ( readfd ); 

22 close ( writefd ); 

23 exit (0); 

24 } 

73 / 97


Systemaufrufe 


named pipe - Beispiel Client/Server cat (Server) 

1 server ( int readfd , int writefd ) { 

2 char buff [ MAXBUFF ]; 

3 char errmesg [256]; 

4 int n, fd; extern int errno ; 

6 /* Read filename from the IPC descriptor . */ 

7 if ( (n = read ( readfd , buff , MAXBUFF )) 0) 

22 if ( write ( writefd , buff , n) != n) 

23 perror (" server : data write error "); 

24 if (n < 0) perror (" server : read error "); 

25 } 

26 } 

74 / 97


Systemaufrufe 


named pipe - Beispiel Client/Server cat (Client) 

client.c fifo.h 

1 main () { 

2 int readfd , writefd ; 

4 /* Open the FIFOs . We assume the server 

5 has already created them . */ 

6 if ( ( writefd = open ( FIFO1 , 1)) < 0) 

7 perror (" client : can 't open write fifo : FIFO1 "); 

8 if ( ( readfd = open ( FIFO2 , 0)) < 0) 

9 perror (" client : can 't open read fifo : FIFO2 "); 

11 client ( readfd , writefd ); 

12 close ( readfd ); 

13 close ( writefd ); 

15 /* Delete the FIFOs , now that we 're finished . 

16 */ 

17 if ( unlink ( FIFO1 ) < 0) 

18 perror (" client : can 't unlink FIFO1 "); 

19 if ( unlink ( FIFO2 ) < 0) 

20 perror (" client : can 't unlink FIFO2 "); 

21 exit (0); 

22 } 

75 / 97


Systemaufrufe 


named pipe - Beispiel Client/Server cat (Client) 

1 client ( int readfd , int writefd ) { 

2 char buff [ MAXBUFF ]; 

3 int n; 

5 /* Read the filename from standard input , 

6 write it to the IPC descriptor . */ 

8 printf (" File to print : "); 

9 if ( fgets (buff , MAXBUFF , stdin ) == NULL ) 

10 perror (" client : filename read error "); 

12 n = strlen ( buff ); 

13 if ( buff [n -1] == '\n') 

14 n - -; /* ignore newline from fgets () */ 

15 if ( write ( writefd , buff , n) != n) 

16 perror (" client : filename write error " );; 

18 /* Read the data from the IPC descriptor and 

19 write to standard output . */ 

20 while ( (n = read ( readfd , buff , MAXBUFF )) > 0) 

21 if ( write (1 , buff , n) != n) /* fd 1 = stdout */ 

22 perror (" client : data write error "); 

23 if (n < 0) 

24 perror (" client : data read error "); 

25 } 

76 / 97


Systemaufrufe 



• Durch den Systemaufruf link kann eine physische 

Datei unter mehreren Namen, auch in 

unterschiedlichen Verzeichnissen, erscheinen. 

• Eine Änderung über den Zugriff mit einem Namen 

wirkt sich immer auf das reale Dateiobjekt aus. 

• Um dies zu realisieren, wird eine Datei in Unix 

eindeutig identifiziert durch ihre inode-Zahl. 

• Ein Verzeichnis ist eine Datei, die eine Anzahl von 

Paaren (inode, Name im ASCII Code) enthält. 

• Durch einen Link wird dann ein neuer Eintrag im 

Verzeichnis erzeugt, der zum selben inode einen 

zusätzlichen Namen einführt. 

• Durch unlink kann man Links wieder löschen. 

Dabei wird nur der Eintrag aus dem Verzeichnis 

entfernt; die Datei bleibt erhalten. 

77 / 97


Systemaufrufe 


sync 

In Unix werden die zuletzt benutzten Blöcke in einem Cache 

(Zwischenspeicher) abgespeichert. 

• Dadurch wird ein erneutes Zugreifen schneller, da dann nicht mehr 

auf die Festplatte zugegriffen werden muss. 

• Wenn ein Fehler auftaucht, bevor die Platte wirklich beschrieben 

(durch write Systemaufruf) wird, so gehen Daten verloren und ein 

inkonsistentes Dateisystem wäre die Folge. 

• Deshalb wird periodisch vom Betriebssystem der sync Systemaufruf 

ausgeführt; er schreibt die Blöcke im Cache auf die Platte. 

• Beim Hochfahren eines Unix Systems wird ein Programm ” 

update“ 

als Hintergrundprozess gestartet, der alle 30 Sekunden einen ” 

sync“ 

Aufruf durchführt. 

78 / 97


Systemaufrufe 

fsync 


Während ” 

sync“ den gesamten Cache synchronisiert, kann man mit dem 


fsync“ die Blöcke einer Datei im Cache synchronisieren 

(z.B. bei Datenbanksystemen bei ” 

commit“). 

fsync.c 


2 int fd; 

3 if ( argc != 2) { 


5 } 

6 if (( fd= open ( argv [1] , O_RDWR )) < 0) { 

7 fprintf ( stderr , " open error \n"); exit (2); 

8 } 

10 /* manipulation of file ... */ 

12 if ( fsync (fd) < 0) { ← 

13 fprintf ( stderr , " sync error \n"); exit (3); 

14 } 

15 } 

79 / 97


Systemaufrufe 


chdir, chroot 

• Um vom aktuellen Verzeichnis in ein anderes Verzeichnis zu 

wechseln, existiert der Systemaufruf chdir. 

Nachdem das aktuelle Verzeichnis mit dem Systemaufruf 

chdir( ” 

/usr/schuette/tmp“) geändert wurde, werden die 

folgenden Aufrufe (create, open), bei denen kein vollständiger 

Pfadname angegeben ist, immer im tmp-Verzeichnis Dateien 

angelegt, bzw. geöffnet. 

• Ein Systemaufruf, mit dem das Root-Verzeichnis bestimmt werden 

kann, ist ” 

chroot“. 

Er wird verwendet, um etwa auf Webservern virtuelle 

Root-Verzeichnisse für unterschiedliche Benutzergruppen definieren 

zu können. 

80 / 97


Systemaufrufe 



In Linux besitzt eine Datei einen Besitzer und 12 Schutzbits in 4 Gruppen. 

Ausführungsmodi Benutzer Gruppe Rest 

[sgd] rwx rwx rwx 

s=setuid r=read 

g=setgpid w=write 

d=directory x=execute 

Durch den Systemaufruf chmod kann die Zugriffsmaske für eine Datei 

gesetzt werden. Die Maske wird dabei oktal angegeben. 

So bedeutet 0644 z.B.: 

0 = 000 Programmaufruf mit Rechten des Aufrufers 

6 = 110 rw- 

4 = 100 r– 

4 = 100 r– 

81 / 97


Systemaufrufe 


chmod 

Das folgende Programm setzt die Zugriffsrechte einer Datei 

(2.Parameter) so wie es die Maske (1. Parameter) angibt. 

simpleChmod.c 

1 # include 


3 int mask ; 

4 if ( argc != 3) { 

5 fprintf ( stderr , " usage %s mask file \n", argv [0]); 

6 exit (1); 

7 } 

8 sscanf ( argv [1] ,"%o" ,& mask ); 

9 if (( chmod ( argv [2] , mask )) < 0) { ← 

10 fprintf ( stderr , " chmod error \n"); 

11 exit (2); 

12 } 

13 } 

82 / 97


Systemaufrufe 


setuid 

Wenn ein Programm gestartet wird, so hat es die Rechte, die der 

Aufrufer des Programms hat. 

• Deshalb kann ein Programm dem Superuser gehören (etwa das 

Programm rm=remove file)), aber der Aufrufer kann nur die Dateien 

löschen, für die er die Rechte hat. 

• Mit dem ” 

setuid“ ( ” 

setgid“) Bits kann man erreichen, dass ein 

Programm mit den Rechten des Besitzers (Gruppe) 

(setuid/setgid=1) abläuft und nicht wie normal mit den Rechten des 

Aufrufers (setuid/setgid=0). 

• Dies wird benötigt, um zum Beispiel die Passwort-Datei durch die 

Ausführung des Kommandos ” 

passwd“ abzuändern. Dazu hat das 

Kommando (=Datei) das setuid-Bit gesetzt. 

Beispiel: passwd 

83 / 97


Systemaufrufe 


access 

Wird ein Programm mit dem setuid-Bit ausgestattet, so kann es nicht 

prüfen, ob der Aufrufer die Rechte auf eine Datei hat, da das Programm 

selbst ja durch das setuid-Bit alle Rechte hat. 

Um per Programm auf die Zugriffsrechte des realen Benutzers zugreifen 

zu können, existiert der Systemaufruf access. Der erste Parameter von 

access“ ist die zu prüfende Datei, der zweite der Zugriffsmodus, der 

” 

geprüft werden soll. 

84 / 97


Systemaufrufe 


access 

Das folgende setuid-Programm prüft, ob eine Datei durch den Benutzer 

geöffnet werden könnte; danach wird die Datei geöffnet. 

access.c 


2 if ( argc != 2) { 


4 } 

5 if ( access ( argv [1] , R_OK ) < 0) { 

6 fprintf ( stderr , " access error \n"); exit (2); 

7 } 

8 if ( open ( argv [1] , O_RDONLY ) < 0) { 

9 fprintf ( stderr , " open error \n"); exit (3); 

10 } 

11 } 

$ ls -l access . txt 

-rw ------- 1 roo roo 6 24. Okt 2011 access . txt 

$ access access . txt 

access error 

$ 

85 / 97


Systemaufrufe 



In Unix ist Datum und Uhrzeit als Anzahl Sekunden, die seit dem ” 

Unix 

Urknall“ (1.1.1970 00:00:00) vergangen sind, abgelegt. 

Alle Datumsangaben, werden so gespeichert und erst in der Anzeige in 

lesbare Form gebracht. Dazu existiert der Systemaufruf ” 

time“, der die 

Sekundenanzahl liefert und Routinen, um diese Intergerzahl in ein 

lesbares Format zu konvertieren. 

now.c 

1 # include 

2 # include 

3 main () { 

4 time_t now ; 

5 now = time ( NULL ); /* now as no. secs since ZERO */ 

6 printf ("%s", ctime (& now )); 

7 } 

86 / 97


Systemaufrufe 



Um die systemweite oder Shell-spezifische Ressourcenverwendung zu 

kontrollieren, existiert das Kommando ulimit. 

$ ulimit -a 

core file size ( blocks , -c) 0 

data seg size ( kbytes , -d) unlimited 

scheduling priority (-e) 0 

file size ( blocks , -f) unlimited 

pending signals (-i) 16001 

max locked memory ( kbytes , -l) 64 

max memory size ( kbytes , -m) unlimited 

open files (-n) 1024 

pipe size (512 bytes , -p) 8 

POSIX message queues ( bytes , -q) 819200 

real - time priority (-r) 0 

stack size ( kbytes , -s) 8192 

cpu time ( seconds , -t) unlimited 

max user processes (-u) 1024 

virtual memory ( kbytes , -v) unlimited 

file locks (-x) unlimited 

$ 

87 / 97


Systemaufrufe 

rlimit 


Mit den Systemaufrufen setrlimit und getrlimit kann man die Ressourcen 

eines Prozesses beschränken. 

getrlimit-cpu.c 

1 # include 

2 # include 



6 struct rlimit rl; /* defines and stores the limits */ 

8 getrlimit ( RLIMIT_CPU , &rl ); /* obtain the current limits . */ 

9 rl. rlim_cur = 1; /* Set a CPU limit of 1 second . */ 

10 setrlimit ( RLIMIT_CPU , &rl ); 

12 /* Do busy work . */ 

13 while (1); 

15 return 0; 

16 } 

88 / 97


Systemaufrufe 


fork Bomben 

Ein Beispiel für nichtlimitierte Ressourcen-Verwendung sind fork-Bomben: 

Programme, die eine Explosion von Prozessen verursachen 1 : 

forkbomb.c 


2 int main ( void ){ 

3 while (1) 

4 fork (); 

5 return 0; 

6 } 

forkbomb.java 

1 public class forkbomb implements Runnable { 

2 public static void main ( String [] args ) { 

3 new forkbomb (). run (); 

4 } 

5 public void run () { 

6 new Thread ( this ). start (); 

7 new Thread ( this ). start (); 

8 } 

9 } 

1 Verhindern durch Eintrag in /etc/security/limits.conf 

@users soft nproc 128 

@users hard nproc 50 89 / 97


Betriebssystemstrukturen 


Hier sollen verschiedene Ansätze für den inneren Aufbau eines 

Betriebssystems gezeigt werden. 

1 Überblick 






Monolithische Systeme 


Virtuelle Maschinen 

90 / 97





Monolithische Systeme sind als Menge von Prozeduren realisiert. 

• Jede Prozedur kann jede andere aufrufen. 

• Eine Struktur ist nicht erkennbar. 

• Das Betriebssystem wird generiert, in dem alle Prozeduren übersetzt 

werden und zu einem ein- zigen grossen Objekt gebunden werden. 

Systemaufrufe werden dabei wie folgt abgebildet: 

• Bei einem Systemaufruf werden die Parameter an eine wohldefinierte 

Stelle (spezielle Register oder Stack) geschrieben, dann wird der 

Aufruf durch einen speziellen Unterbrechungsbefehl (Kernel-Aufruf, 

Supervisor-Aufruf) zur Ausführung gebracht. Durch diese Instruktion 

wird die Hardware vom User-Modus in den Kernel-Modus 

umgeschaltet und die Kontrolle übernimmt das Betriebssystem. 

• Das Betriebssystem prüft die Parameter des Aufrufs, bestimmt 

welcher Systemaufruf durchgeführt werden soll. 

• Der Systemaufruf wird vom Betriebssystem ausgeführt und das 

Ergebnis wird wieder in speziellen Registern oder auf dem Stack 

abgelegt. 

• Dann gibt das BS die Kontrolle an das Benutzerprogramm zurück. 

91 / 97




Systemaufrufe 

• Diese Vorgehensweise wird von 

den meisten CPUs unterstützt. 

• Eine CPU kann in zwei Modi 

gefahren“ werden: im 

” 

Kernel-Modus sind alle 

Instruktionen zulässig, im 

User-Modus nur eingeschränkte 

Instruktionen, hauptsächlich 

E/A Befehle. 

92 / 97





Ein Betriebssystem dieser Kategorie ist in Schichten eingeteilt, wobei eine 

Schicht auf der Basis der darunter liegenden Schicht konstruiert ist. Das 

klassische Beispiel ist das von Dijkstra 1968 entwickelte System THE 

(Technische Hogeschool Eindhoven). 

• Schicht 0 war für das Prozess-Scheduling verantwortlich, dadurch 

brauchte keine der anderen Schichten mehr zu berücksichtigen, dass 

es mehrere Prozesse auf der Maschine gibt. 

• Schicht 1 belegte für einen Prozess Platz im Speicher; war dort 

kein Platz wurden Speicherseiten auf eine Trommel verlagert; 

dadurch brauchte kein Programm der Schichten 2 und grösser sich 

um Speicherverwaltung zu kümmern. 

• Schicht 2 verwaltete die Bedienkonsole und die Kommunikation 

zwischen Prozessen; damit hatte ab der Schicht 3 jedes Programm 

seine eigene virtuelle Konsole. 

• Schicht 3 war für die Verwaltung der E/A-Geräte zuständig; 

damit konnte jedes Programm ab Ebene 4 mit logischen 

E/A-Geräten arbeiten. 

93 / 97




Somit hatten Benutzerprogramme eine virtuelle Sicht auf die 

Hardware. 

Diese Konzeption war eine Entwurfentscheidung. 

Das gesamte Betriebssystem war aber immer noch ein aus mehreren 

Modulen zusammengefasstes grosses Programm. 

94 / 97





Das IBM System VM/370 stellt einen Monitor zur Verfügung, der auf die 

nackte“ Hardware zugreift und Kopien der realen Maschine als virtuelle 

” 

Maschine für darüber liegende Schichten bereitstellt. 

• Auf jeder solcher virtuellen Maschinen 

kann ein eigenes BS ablaufen. 

• Wenn ein Benutzerprogramm einen 

Systemaufruf absetzt, wird er vom BS 

der virtuellen 370 behandelt. Dort gibt 

dieses BS den Aufruf nicht an die reale 

Hardware weiter, sondern an den 

Monitor, der dann den Zugriff auf die 

Hardware erledigt. 

Diese Architektur ist noch Heute Basis der ” 

grossen“ IBM 

Betriebssysteme. 

95 / 97



Auftraggeber-Auftragnehmer Modell 


In modernen Betriebssystemen verwendet man das 

Auftraggeber-Auftragnehmer Modell (Client- Server Modell). 

• Ein Client-Prozess beauftragt einen Server, 

einen Dienst auszuführen, indem er dem 

Server eine Nachricht sendet. 

• Der Server antwortet mit der Erbringung des 

Dienstes. 

• Sowohl Client als auch Server laufen im 

User-Modus. 

• Dadurch hat der Betriebssystemkern nur noch 

elementare Aufgaben, wie z.B. 

Interprozesskommunikation. 

Der schlanke Kern und die unabhängigen Server bewirken, dass gut 

skalierbare und fehlertolerante Betriebssysteme realisierbar sind: ein 

Absturz des Datei-Servers führt nicht zum Absturz der davon nicht 

betroffenen Programme. 

96 / 97




Verteilte Betriebssysteme 

Weiterhin ist damit die Voraussetzung für verteilte Betriebssysteme 

gesetzt: 

• im Kern wird Netzfunktionalität integriert und 

• die Server können auf beliebigen Rechnern im Netz ablaufen. 

97 / 97

Betriebssysteme - Einleitung

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?