mse course student

Eingebettete vernetzte Systeme (IN8014) -Teil I: Betriebssysteme und Systemsoftware

Johann SchlichterInstitut fr Informatik

TU Mnchen, Munich, Germany

September 2012Vorlesungsunterlagen

(Student Script1)

1Script generated by Targeteam; Not for general Distribution

Inhaltsverzeichnis

1 bersicht 21.1 Ziele dieses Vorlesungsteils . . . . . . . . . . . . . . . . . . . . . 2

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Anforderungen an Rechensysteme . . . . . . . . . . . . . 3

1.2.2 Struktur eines Rechensystems . . . . . . . . . . . . . . . 5

1.3 Literaturbersicht . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Begleitend zur Vorlesung . . . . . . . . . . . . . . . . . . 6

1.3.2 Weiterfhrende Literatur . . . . . . . . . . . . . . . . . . 6

2 Einfhrung 72.1 Betriebssystem - berblick . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 BS-Hauptaufgaben . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Systemprogrammierung . . . . . . . . . . . . . . . . . . 10

2.1.3 Hardwarekomponenten . . . . . . . . . . . . . . . . . . . 11

2.1.4 Betriebsarten . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Betriebssystem-Architektur . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Monolithischer Ansatz . . . . . . . . . . . . . . . . . . . 13

2.2.2 Mikrokern-Ansatz . . . . . . . . . . . . . . . . . . . . . 15

2.2.3 Beispiel: BS-Architekturen . . . . . . . . . . . . . . . . . 16

2.2.4 Systemaufrufe . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.5 Virtuelle Maschine . . . . . . . . . . . . . . . . . . . . . 19

3 Synchronisation und Verklemmungen 213.1 Thread-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Charakterisierung von Threads . . . . . . . . . . . . . . . 22

i

Schlichter, TU Mnchen INHALTSVERZEICHNIS

3.2 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Beispiel: gemeinsame Daten . . . . . . . . . . . . . . . . 24

3.2.2 Synchronisierungskonzepte . . . . . . . . . . . . . . . . 26

3.2.3 Semaphore . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.4 Synchronisierung von Java Threads . . . . . . . . . . . . 34

3.3 Verklemmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.2 Belegungs-Anforderungsgraph . . . . . . . . . . . . . . . 36

3.3.3 Verklemmungs-Ignorierung . . . . . . . . . . . . . . . . 37

3.3.4 Verklemmungs-Erkennung . . . . . . . . . . . . . . . . . 37

3.3.5 Verklemmungs-Verhinderung . . . . . . . . . . . . . . . 38

3.3.6 Verklemmungs-Vermeidung . . . . . . . . . . . . . . . . 38

3.3.7 Vergleich der Anstze . . . . . . . . . . . . . . . . . . . 41

4 Prozess- und Prozessorverwaltung 424.1 Fragestellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Prozessverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.1 Prozesskonzept . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.2 Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2.3 Arbeitsmodi . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2.4 Systemaufrufe . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.5 Realisierung von Threads . . . . . . . . . . . . . . . . . 51

4.3 Prozessorverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.1 Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.2 Scheduling-Strategien . . . . . . . . . . . . . . . . . . . 54

4.3.3 Thread Scheduling . . . . . . . . . . . . . . . . . . . . . 58

4.3.4 Mehrschichtiges Scheduling . . . . . . . . . . . . . . . . 58

4.3.5 Echtzeit Scheduling . . . . . . . . . . . . . . . . . . . . 60

4.4 Unterbrechungskonzept . . . . . . . . . . . . . . . . . . . . . . . 61

4.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4.2 Unterbrechungsarten . . . . . . . . . . . . . . . . . . . . 61

4.4.3 Behandlung externer Unterbrechungen . . . . . . . . . . 63

4.4.4 Konflikte . . . . . . . . . . . . . . . . . . . . . . . . . . 64

ii


5 Speicherverwaltung 675.1 Fragestellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2.1 Adressrume . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2.2 Organisation von Adressrumen . . . . . . . . . . . . . . 68

5.2.3 Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . 70

5.2.4 Forderungen an Adressraumrealisierung . . . . . . . . . . 72

5.3 Speicherabbildungen . . . . . . . . . . . . . . . . . . . . . . . . 72

5.3.1 Direkte Adressierung . . . . . . . . . . . . . . . . . . . . 72

5.3.2 Basisadressierung . . . . . . . . . . . . . . . . . . . . . . 74

5.3.3 Seitenadressierung . . . . . . . . . . . . . . . . . . . . . 75

6 Prozesskommunikation 786.1 Fragestellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2.1 Kommunikationsarten . . . . . . . . . . . . . . . . . . . 78

6.3 Nachrichtenbasierte Kommunikation . . . . . . . . . . . . . . . . 82

6.3.1 Elementare Kommunikationsmodelle . . . . . . . . . . . 82

6.3.2 Erzeuger-Verbraucher Problem . . . . . . . . . . . . . . . 86

6.3.3 Modellierung durch ein Petrinetz . . . . . . . . . . . . . . 87

6.3.4 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3.5 Kanle . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.6 Strme . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.4 Client-Server-Modell . . . . . . . . . . . . . . . . . . . . . . . . 90

6.5 Netzwerkprogrammierung . . . . . . . . . . . . . . . . . . . . . 92

6.5.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.5.2 Server Protokoll . . . . . . . . . . . . . . . . . . . . . . 94

6.5.3 Client Protokoll . . . . . . . . . . . . . . . . . . . . . . . 95

6.5.4 Bidirektionale Stromverbindung . . . . . . . . . . . . . . 95

6.5.5 Java Socket Class . . . . . . . . . . . . . . . . . . . . . . 96

7 Zusammenfassung 99

iii


Prof. J. Schlichter

Lehrstuhl fr Angewandte Informatik / Kooperative Systeme, Fakultt frInformatik, TU Mnchen

Boltzmannstr. 3, 85748 GarchingEmail: [email protected] (URL: mailto:[email protected])Tel.: 089-289 18654URL: http://www11.informatik.tu-muenchen.de/

1

Kapitel 1

bersicht

1.1 Ziele dieses Vorlesungsteils

Diese Vorlesung beschftigt sich mit den technischen Aspekten von Rechensyste-men und der Informationsverarbeitung, nmlich der systemnahen Programmie-rung. Dabei werden in diesem Teil der Vorlesung vor allem Aspekte allgemeinerBetriebssysteme und Prozesskommunikation betrachtet. Der 2. Teil der Vorlesungbehandelt dann die Echtzeitaspekte.

Zunchst werden informell die Aufgaben und Eigenschaften eines Betriebssy-stem dargestellt. Daraus lassen sich die fr die Vorlesung relevanten Begriffeableiten. Weiterhin wird kurz auf Hardware-nahe Programme eingegangen.

Im nchsten Teil der Vorlesung erfolgt der bergang von sequentiellen zuparallelen Systemen. Zu den Themen, die behandelt hier werden, gehren dieGrundlagenprobleme paralleler Systeme und die Verfahren, mit denen diesegelst werden knnen: Synchronisation, Verklemmungen.

Im Anschluss daran werden Konzepte und Verfahren von Betriebssystemen,die der wesentliche Teil der Konkretisierung paralleler Systeme sind, behan-delt. Insbesondere geht es um die Arbeitsspeicherverwaltung (Arbeitsspeicher-verwaltung, "main memory management"), die Prozessverwaltung und die Pro-zessorzuteilung sowie Mechanismen zur Kontrolle der Nebenlufigkeit.

Prozesse existieren nicht in Isolation, sondern die Kommunikation zwischen denProzessen ist von zentraler Bedeutung fr Lsung vieler Problemstellungen.Der Austausch von Information zwischen Prozessen kann entweder speicher-basiert oder ber Nachrichten erfolgen. Die nachrichtenbasierte Prozesskom-

2

Schlichter, TU Mnchen 1.2. MOTIVATION

munikation ist gerade fr verteilte Rechensysteme, wo Prozesse ber ein (lo-kales oder globales) Rechnernetz miteinander kommunizieren, von groer Be-deutung. Wichtige Aspekte sind hierbei das Client-Server Modell und die Netz-werkprogrammierung.

1.2 Motivation

Aufgabe der Informatik ist es, Rechensysteme zu entwickeln und diese Anwen-dern als leistungsfhige Hilfsmittel fr Lsungen ihrer Informationsverarbei-tungsprobleme zur Verfgung zu stellen.

1.2.1 Anforderungen an Rechensysteme

Rechensysteme sind

offene, dynamische, technische Systeme

mit Fhigkeiten zur Speicherung und zur

Verarbeitung von Information, die fr Anwendungen und Anwender nutzbarzur Verfgung gestellt werden sollen.

Offenes System

Ein Rechensystem R ist ein offenes System sagt zweierlei aus:

R ist als System eine durch Zusammenfassung gebildete, abgegrenzte Einheit,wo zwischen innen (R) und auen (U(R)) unterschieden wird.

R hat eine (offene) Schnittstelle, mit der Einwirkungen von U(R) auf R undEinwirkungen von R auf U(R) mglich sind.

Schnittstelle eines Rechensystems

3


Umgebung

U(R)

Rechensystem R

Schnittstelle R - U(R)

Dynamisches System

Eigenschaften des Rechensystems R ndern sich mit der Zeit

Beschreibung des Verhaltens von R.

Technisches System

Das Rechensystem ist mit hardware- und softwaretechnischen Mitteln realisiert.

Informationsspeicherung und -verarbeitung

4


Information

Daten

Information

Daten

Nachricht

Wissen

Reprsentation Interpretation

1.2.2 Struktur eines Rechensystems

Datenbank World Wide Web Email

Shell bersetzer Dateisystem

Betriebssystem

Maschinensprache

Mikroprogramme / festverdrahtete Programme

physische Komponenten und Gerte

Hardware

Systemprogramme

Anwendungs-

programme

Darstellung von Programmen in maschinennaher Form fr bestimmte Anwen-

5

Schlichter, TU Mnchen 1.3. LITERATURBERSICHT

dungen auch heute noch unerllich, beispielsweise fr den bersetzerbau, ein-gebettete Systeme oder fr systemnahe Programmierung in Teilen des Betriebs-systems.

Thema der Vorlesung ist systemnahe Programmentwicklung; nebenlufige("concurrent") Ausfhrung von mehreren Teilablufen Nichtdeterminismus.

1.3 Literaturbersicht

Literatur, die als Basis fr diesen Vorlesungsteil verwendet wird.

1.3.1 Begleitend zur Vorlesung

Andrew S. Tanenbaum, "Modern Operating Systems", Prentice Hall, 2008;dazu gibt es eine deutsche bersetzung

Andrew S. Tanenbaum, "Moderne Betriebssysteme", Pearson Studium,2009

Abraham Silberschatz, Peter Galvin, Greg Gagne, " Operating SystemConcepts. Operating System Concepts", Wiley & Sons, 2009

1.3.2 Weiterfhrende Literatur

Albrecht Achilles, "Betriebssysteme - Eine kompakte Einfhrung mit Linux",Springer, 2006

Eduard Glatz, "Betriebssysteme - Grundlagen, Konzepte, Systemprogrammie-rung", dpunkt.verlag, 2010

William Stallings, "Operating Systems - Internals and Design Principals",Pearson International Edition, 2011

George Coulouris, Jean Dollimore, Tim Kindberg, "Distributed Systems -Concepts and Design", Addison-Wesley, 2012

Andrew S. Tanenbaum, Marten van Steen, "Verteilte Systeme - Grundlagen undParadigmen", Pearson Studium, 2007

6

Kapitel 2

Einfhrung

Definition eines Betriebssystems nach DIN 44300:

Das Betriebssystem wird gebildet durch die Programme eines digitalenRechensystems, die zusammen mit den Eigenschaften der Rechenanlage dieGrundlage der mglichen Betriebsarten des digitalen Rechensystems bildenund insbesondere die Ausfhrung von Programmen steuern und berwachen.

2.1 Betriebssystem - berblick

Ein Betriebssystem realisiert die Schnittstelle zwischen dem Benutzer und derphysischen Rechenanlage. Aus der Sicht des Benutzers entsteht durch ein Be-triebssystem eine virtuelle Maschine. Fr einen Benutzer ist es nicht wichtig, ob ineinem Rechensystem Systemfunktionen durch Hardware oder Software realisiertsind. Ein Betriebssystem realisiert insbesondere eine Benutzerschnittstelle. DerEntwurf und die Implementierung von Betriebssystemen gehren zu den klassi-schen Aufgabenstellungen der Systemprogrammierung. Je nach Art der Hardwaregibt es sehr unterschiedliche Typen von Betriebssystemen. Sie reichen von Be-triebssystemen fr Grorechner, ber Server-BS bis hin zu PC-Betriebsystemenund eingebetteten Betriebssystemen (z.B. in einem Android Smartphone).

2.1.1 BS-Hauptaufgaben

Ein Betriebssystem (engl. operating system) erfllt folgende Hauptaufgaben:

Veredeln der Hardware (Virtualisierung). Steuerung und Kontrolle der Programmausfhrung.

7

Schlichter, TU Mnchen 2.1. BETRIEBSSYSTEM - BERBLICK

Interprozesskommunikation. Verwaltung der Ressourcen (Speicher, CPU, Platten, Netz etc.) Betriebssy-

stem kann als Ressourcenverwalter gesehen werden.

RessourcenklassenEin Rechensystem kann als strukturierte Sammlung von Ressourcenklassenbetrachtet werden, wobei jede Klasse durch Dienste des Betriebsystemskontrolliert wird.

Zentral Ressourcen Periphere Ressour-cen

Aktive Ressourcen Prozessoren (CPUs) Kommunikationseinheitenwie Endgerte ( Tasta-tur, Drucker, Monitor,Maus) und Netzwerk(lokal, entfernt)

Passive Ressourcen Arbeitsspeicher Speichereinheiten wieFestplatten, CD, DVD

Anbieten von Diensten in Form von Schnittstellen, so dass die Ressourcengenutzt werden knnen Hardwareunabhngige Programmierschnittstelle,z.B. gerteunabhngige Ein-/Ausgabefunktionen.

Sicherheitsmechanismen. Arbeitsmodi des Betriebssystems

Operationen des Betriebssystems und der Hardware mssen vor Programmier-fehlern in Anwendungsprogrammen geschtzt werden Einfhrung eines Pri-vilegiensystems.

Benutzermodus (user mode): Ausfhrung von Benutzerprogrammen,kein direkter Hardware-Zugriff, keine privilegierten Befehl, nur virtuelleAdressen.

Systemmodus (kernel mode): Ausfhrungsmodus der Dienste des BS-Kerns, privilegierte Befehle erlaubt.

Benutzermodus Systemmodusbegrenzte Auswahl von Maschinen-befehlen

alle ausfhrbaren Maschinenbefehle

Hardwarezugriff nur ber BS Vollzugriff auf Hardwarekein bzw. nur lesender Zugriff aufSystemcode oder Daten

exklusiver Zugriff auf Systemcodeund Daten

8


Benutzerprozess

Betriebssystemkern

Ausfhrung

Benutzerprozess

System

Aufruf

Ausfhrung

Systemdienst

Rckkehr von

System AufrufBenutzermodus

Systemmodus

Struktureller Aufbau

Speicher

verwaltung

Prozess

verwaltung

Datei

system

Scheduler &

Dispatcher

EA-

System

Unterbrechungs-

System

Hardware

Konfiguration

Betriebssystem-Schnittstelle

Z

u

g

a

n

g

s

k

o

n

t

r

o

l

l

e

Benutzer-

Prozesse

System-

Prozesse

Schnittstelle zur Systemumgebung

berechtigte

Benutzer

berechtigte

Benutzer

login

zu berprf.

Benutzer

Ein anderer Blickwinkel

9


NY Times, Sept, 3, 1997: A decade ago, an "operating system" was just thebasic piece of software that ruled the machine and allowed it to manipulatefiles, converse with any peripherals, and start up programs. That was when acomputer was just a nerd toy, not the foundation for the most vital part of ofour economy. But today, an "operating system" is much more a vote over whogets to be the richest men in the world. Windows means Microsoft, Java meansSun, while MacOs means That Steve Jobs wont go broke saving Apple. Linuxmeans no one gets rich because the OS is free, thanks to the help of manyvolunteers.

2.1.2 Systemprogrammierung

Die Programmierung eines Betriebssystems gehrt zu dem Bereich der System-programmierung.

DefinitionDie Systemprogrammierung befasst sich mit der Darstellung, der Realisierung,den Eigenschaften und der Konstruktion derjenigen Algorithmen fr einRechensystem, die die Bearbeitung und Ausfhrung von Benutzerprogrammenunter vorgegebenen Qualittsgesichtspunkten organisieren, d.h. steuern undkontrollieren, und zum Teil selbst durchfhren.

direkte Nutzung der generischen Systemprogrammierschnittstelle des BS.

meist in Programmiersprache C.

Qualittskriterien knnen z.B. sein:

Zuverlssigkeit der durchgefhrten Berechnung (Behandlung von System-crashs, Netzausfllen, fehlerhafter Nachrichtenbermittlung etc.).

Effizienz und Performanz einerseits systemglobal, d.h. es wird versucht,das System optimal auszulasten, andererseits Auftrags-lokal, z.B. es wirdversucht, zu garantieren, dass eine Auftragsbearbeitung eine festgelegteZeitdauer nicht berschreitet.

Einhaltung von Realzeitanforderungen: zeitkritische Auftrge besitzen z.B.eine Deadline bis zu der sie ausgefhrt sein mssen.

Durchsetzung von Sicherheitsanforderungen: Schutz der Daten und Informa-tionen vor unberechtigten Zugriffen und Einsichtnahme.

Benutzerfreundlichkeit: bequeme Formulierungsmglichkeit von Benutzer-auftrgen.

10


2.1.3 Hardwarekomponenten

Das Betriebssystem ist sehr eng mit der Hardware des Rechensystems verknpft,auf dem es ausgefhrt wird. Es erweitert den Befehlssatz des Rechners undverwaltet seine Ressourcen.Deshalb an dieser Stelle einen kurzen berblick ber den Aufbau einesRechensystems.

CPU

Drucker

Northbridge Arbeitsspeicher

Systembus Speicherbus

USB

AGP

PCI Bus

EA-Karte

Grafik

EA-Karte

Sound

Southbridge

IDE

Festplatte

ISA Bus

(Maus,

Tastatur)

EA-Karte

LAN

PCI = Peripheral Component InterconnectISA = Industry Standard ArchitectureUSB = Universal Serial BusAGP = Accelerated Graphics Port (Anschluss von schnellen Grafikkarten).

2.1.4 Betriebsarten

Beim Betrieb von Rechenanlagen knnen bzgl. des Zusammenwirkens von Be-nutzer und Rechensystem die Betriebsweisen Stapelverarbeitung, Dialogbetrieb,Transaktionsbetrieb und Echtzeitbetrieb unterschieden werden.

11


StapelbetriebDas Rechensystem verarbeitet Strme von Auftragspaketen (engl. batch pro-cessing). Ein Benutzer deklariert vollstndig alle Teile eines Auftragspaketes,bevor es in das System eingegeben wird. Anschlieend wird das Auftragspa-ket durch das Rechensystem abgearbeitet, ohne dass der Benutzer noch Ein-flussmglichkeiten hat. Bei Auftreten eines Fehlers muss i.a. nach der Korrekturdas gesamte Auftragspaket nochmals gestartet werden. Auftragspakete knnenin Unterabschnitte zerfallen, z.B. Teilprogrammablufe. Diese Betriebsart warin den Anfngen von Rechenanlage sehr verbreitet (Nutzung von Lochkartenund Lochstreifen).

DialogbetriebIm Dialogbetrieb (engl. Timesharing) erteilt der Benutzer dem Betriebssystemeinen Auftrag nach dem anderen im Dialog. Innerhalb eines Benutzerauftragsfindet eine Interaktion zwischen dem Benutzer und der Systemumgebungstatt (z.B. Eingabe weiterer Daten, Ausgabe von Zwischenergebnissen). DerDialogbetrieb erfordert eine besondere Gestaltung der Benutzerschnittstelle.Oft wird Betriebssystem und Benutzerschnittstelle (engl. user interface) ineinem Atemzug genannt und auch oft gleichgesetzt. Beide sind jedoch getrenntvoneinander zusehen. Beispielsweise existierten mit dem X11-Windowsystemund Sun Windowsystem (auf der Basis von Postscript) zwei unterschiedlicheBenutzerschnittstellen auf demselben Betriebssystem.

TransaktionsbetriebBewltigung einer Vielzahl von kleinen Aufgaben in krzester Zeit, z.B.Bankberweisungen oder Buchungen. Dabei muss die Bearbeitung folgendeKriterien, wie sie auch von Datenbanken bekannt sind, erfllen: Atomaritt,Konsistenz, Isolation, Dauerhaftigkeit (engl. ACID), d.h. die Bearbeitung mussentweder vollstndig ablaufen oder keinerlei nderung verursachen (Alles-oder-nichts Prinzip).

EchtzeitbetriebIn der Prozesssteuerung (automatische Fertigungssysteme, Roboter) und imMultimediabereich sind die Reaktionszeiten des Betriebssystems von groerBedeutung. Dies erfordert spezielle Mechanismen bei der Behandlung vonEreignissen und Unterbrechungen sowie der CPU-Zuteilung an rechenbereiteProzesse / Threads. Beispielsweise ein Videoserver (bei Nutzung des StreamingAnsatzes) bentigt ein Betriebssystem, das gewisse Echtzeitfhigkeiten hat.Videos mssen mit einer bestimmten Geschwindigkeit abgespielt werden. DieBilder drfen an das Abspielprogramm nicht zu langsam (ansonsten ruckelt

12

Schlichter, TU Mnchen 2.2. BETRIEBSSYSTEM-ARCHITEKTUR

das Videobild) und nicht zu schnell ausgeliefert werden (sonst gehen beiPufferberlauf Videobilder verloren). Unterscheidung zwischen

harte Echtzeitsysteme: Reaktionszeit darf nicht berschritten werden.

weiche Echtzeitsysteme: gewisse Toleranzen bzgl. der Abweichung sinderlaubt.

2.2 Betriebssystem-Architektur

In der Praxis findet man einige verschiedene BS-Architekturkonzepte, wobei dermonolithische Ansatz und zunehmend auch der Mikrokern-Ansatz am weitestenverbreitet sind.

2.2.1 Monolithischer Ansatz

Das Betriebssystem besteht aus einer umfangreichen Menge an Funktionen,die sich bei Bedarf gegenseitig aufrufen knnen. Die Funktionen werden ineinem groen BS-Kern zusammengefasst. Der BS-Kern wird durch Aufruf vonSystemdiensten betreten.

BS-Kern arbeitet im Systemmodus.

Er hat hohe Ablaufprioritt.

Er ist permanent im Arbeitsspeicher.

13


Anwendung

Benutzerprozess

Anwendung

Benutzerprozess

Benutzer-Modus

(User Mode)

System-Modus

(Kernel Mode)Systemdienste

(Hauptprozedur)

Hardware

Hilfs

funktionen

komplexe, monolithische Betriebssystem sind sehr schwierig zu warten und zuerweitern.

Geschichtete SystemeEinen Ausweg aus der Problematik monolithischer Systeme bieten geschichteteSysteme;

das Betriebssystem besteht aus einer Hierarchie abstrakter Maschinen.

Jede Schicht hat wohldefinierte Schnittstellen und eine wohldefinierteAufgabe

Reduktion der Systemkomplexitt.

14


Anwendungen

abstrakte Maschine N

Funktionsschnittstelle

abstrakte Maschine N - 1


abstrakte Maschine 0


Rechnerhardware

Schicht N

Schicht N-1

Schicht 0

2.2.2 Mikrokern-Ansatz

Der Trend moderner Betriebssystem geht hin zu einem Mikrokern-Ansatz. ImMikrokern sind nur mehr Basismechanismen, z.B. Prozesskommunikation (Aus-tausch von Nachrichten), CPU-Zuteilung. Mglichst viele Subsysteme sind alsSystemprozesse auerhalb des Mikrokerns realisiert. Sie laufen im Benutzer-modus ab, z.B. Dateisystem, Verwaltungsstrategien, Speicherverwaltung. Manspricht im Zusammenhang mit diesem Ansatz auch von einer Client/Server-Struktur. Systemfunktionen werden als Serverprozesse im Benutzermodus aus-gefhrt. Bentigt ein Prozess (Client) eine Dienstleistung schickt er eine Anfor-derung an einen anderen Prozess (Server), der die Dienstleistung erfllt und dieAntwort an den Client zurckgibt. Die Kommunikation zwischen den beteiligtenProzessen erfolgt ber den Mikrokern. Durch die Ausgliederung in Serverpro-zesse ist eine Trennung von Mechanismus und Strategie mglich. Die Strategienwerden in Serverprozessen im Benutzermodus realisiert, whrend der Mikrokernwenige Basismechanismen umfasst.

15


Einfaches Austauschen von Subsysteme ermglicht die einfache Anpas-sung von Systemanforderungen.

Benutzer-Modus

(User Mode)

System-Modus

(Kernel Mode)

Mikrokern

Hardware

Benutzer

Programm

Prozess

Server

Memory

Server

File

Server

Netzwerk

Server

Display

Server

Anforderung

Antwort

2.2.3 Beispiel: BS-Architekturen

Unix Betriebssystem

Die nachfolgende Abbildung skizziert die wesentlichen Komponenten desUnix Betriebssystems. Der Unix-BS-Kern enthlt die Datei-, Prozess- undProzessorverwaltung, die Speicherverwaltung und die Gerte-Treiber.

Hardware

Gerte Treiber

Datei

System

Unterbrechungs

behandlung

Prozess

verwaltung

Prozessor

verwaltung

Arbeitsspeicher

verwaltung

Systemschnittstelle

u.a. open,close, read, write; fork, exec, kill, ...

Programme ShellsBibliotheken

(z.B. lib.a)

Betriebs-

systemkern

Programmier-

schnittstelle

Benutzungs-

schnittstelle

16


Windows NT Betriebssystem

Mit Hilfe von HAL wird versucht, die meisten Maschinenabhngigkeiten zuverbergen. HAL prsentiert dem restlichen BS abstrakte Hardwaregerte (z.B.Systembus, Arbeitsspeicher etc).

Hardware

Hardware Abstraction Layer (HAL)

Kernel

Object

Manager

Security

Manager

Process

Manager

Local

Procedure

Call Facility

Virtual

Memory

Manager

System Services

I/O Manager

File

SystemsCache Mgr

Device

DriversNetwork

Drivers

Hardware Manipulation

User Mode

Kernel Mode

Win32

Subsystem

Security

Subsystem

OS/2

Subsystem

Posix

Subsystem

Logon

ProcessOS/2 Client Win32 Client Posix Client

Systemaufrufe

NT Executive

Protected

Subsysteme

(Servers)

Applications

System Interface (DLL)

Linux Betriebssystem

Linux begann Anfang der 1990er Jahre als eine Unix Variante fr den IBM PC;

erste Version durch Linus Torvalds (1991).

Linux ist frei und Quellcode ist verfgbar.

kollaborative Weiterentwicklung durch Open Source Community.

kein Mikrokern-Ansatz, jedoch modulare Struktur.dynamic linking.

Module sind hierarchisch organisiert.

jeder Modul ist durch 2 Datenstrukturen beschrieben.

17


Modulbeschreibung, u.a Modulname, Gre, Zahl der exportierten Symbo-le und referenzierte Module.

Symbol-Tabelle.

Prozesse

Processes &

scheduler

System

callsSignals

Virtual

memory

Traps

faults

Physical

memory

device driver

(Char)

Interrupt

Device driver

(Block)

File systemNetwork

protocols

Network

driver

user mode

kernel mode

CPU Main memory terminal diskNetwork interface

controller

2.2.4 Systemaufrufe

Die Schnittstelle zwischen dem Betriebssystem und den Benutzerprogrammenwird durch eine Menge von Systemaufrufen (engl. system calls) gebildet. Siestellen fr Benutzerprogramme die einzige Schicht zum Zugriff auf Dienste desBetriebssystems and damit zur Nutzung der Hardware dar.

in Benutzerprogrammen werden Systemaufrufe nicht direkt verwendet, sonderndies erfolgt ber die Einbindung von Systembibliotheken, z.B. C-Library.

18


main ( ) {

--------------

printf ("hello);--------------

}

-------------

printf erledigt Formatierung

--------------

Systemaufruf

Anwendung

Bibliotheksfunktion

-------------

write (1, "hello, 5);--------------

Betriebssystemkern

Z.B. Zugriff auf FestplatteHardware

Benutzermodus

Systemmodus

Systemaufruf fhrt zum bergang vom Benutzermodus in den Systemmodus. Beispiele von Systemaufrufen

Prozessmanagement: fork, waitpid, exit.

Dateimanagement: open, close, read, write.

Verzeichnismanagement: mkdir, rmdir, link, mount.

Gertemanagement: request/release device, get/set device attributes.

Kommunikationsmanagement: send/receive messages, create/deleteconnection.

2.2.5 Virtuelle Maschine

Virtualisierungskonzept erlaubt die gleichzeitige Bereitstellung mehrerer Be-triebssysteme auf einem Rechner.

Isolierung der virtuellen Maschinen.

gemeinsame Nutzung von Dateien mglich.

Beispiel VMware (URL: http://www.vmware.com/).

19


Hardware

CPU Arbeitsspeicher E/A-Gerte

Host Betriebssystem

(Linux)

Applikation Applikation Applikation

Virtualisierungsschicht

Gast-Betriebssystem

(free BSD)

virtuelle CPU

virtueller Speicher

virtuelle Gerte

Gast-Betriebssystem

(Windows XP)

virtuelle CPU

virtueller Speicher

virtuelle Gerte

Die Java Virtual Machine (JVM) spezifiziert einen abstrakten Computer, auf demJava Programme ausgefhrt werden. JVM ist ein Softwaresystem, das auf demHost-Betriebssystem ausgefhrt wird.

20

Kapitel 3

Synchronisation undVerklemmungen

Historisch gesehen war der Ausgangspunkt eine Ein-Benutzer, Ein-ProgrammRechenanlage und zwar ohne ein Betriebssystem, das die Ausfhrung vonProgrammen koordiniert. Fr die Ausfhrung von mehreren Programmen,insbesondere wenn sie parallel ausgefhrt werden sollen, sind eine Reihe vonorganisatorischen Manahmen notwendig. Die angesprochenen organisatorischenAufgaben sind wesentlicher Bestandteil der Aufgaben eines Betriebssystemsund die Programmierung eines Betriebssystems gehrt zu dem Bereich dersystemnahen Programmierung. Typischerweise finden in einem allgemeinenRechensystem eine Vielzahl paralleler Ablufe statt, die miteinander koordiniertwerden mssen.

3.1 Thread-Konzept

Threads sind ein BS-Konzept fr die Realisierung von nebenlufigen Aktionenin einem Rechensystem. Threads (Kontrollflsse) beschreiben die Aktivitten ineinem Rechensystem. Sie knnen als virtuelle Prozessoren aufgefasst werden, diejeweils fr die Ausfhrung eines zugeordneten Programms in einem Adressraumverantwortlich sind. Threads konkurrieren um die physische CPU, um ablaufenzu knnen. In traditionellen Umgebungen hat jeder Prozess genau einen Thread,der den Kontrollfluss des Prozess reprsentiert, whrend in Multithreaded-Umgebungen ein Prozess mehrere Threads besitzen kann.

21

Schlichter, TU Mnchen 3.1. THREAD-KONZEPT

Prozess

Thread Thread

Benutzer

Adressraum

Betriebssystem

3.1.1 Charakterisierung von Threads

Aus BS-Sicht ist ein Prozess definiert

durch einen Adressraum.eine darin gespeicherte Handlungsvorschrift in Form eines sequentiellenProgramms (Programmcode).einen oder mehreren Aktivittstrgern, die dynamisch die Handlungsvor-schrift ausfhren Threads.

Motivation

Ein Thread ist die Abstraktion eines physischen Prozessors; er ist ein Trger einersequentiellen Aktivitt. Grnde fr die Einfhrung von Threads:

mehrere Threads ermglichen Parallelitt innerhalb eines Prozesses unterNutzung des gemeinsamen Adressraums.

Aufwand fr Erzeugen und Lschen von Threads ist geringer als fr Prozesse.Threads fhren nicht so einen groen Ballast an Information mit sich alsProzesse. Beispielsweise muss bei der Erzeugung eines Prozesses durchdas BS ein neuer Adressraum generiert werden; Threads laufen im bereitsvorhandenen Adressraum ab. Deshalb spricht man bei Threads auch vonLeichtgewichtsprozesse ("light weight processes"), da sie erheblich wenigerVerwaltungsinformation als normale Prozesse ("heavy weight processes")bentigen.

Verbesserung der Performanz der Applikationsausfhrung durch Nutzungmehrerer Threads. Dieses Argument ist besonders dann von Bedeutung, wenn

22

Schlichter, TU Mnchen 3.1. THREAD-KONZEPT

die Applikation (und damit der zugehrige Prozess) sowohl CPU- als auch E/A-intensive Aktivitten beinhaltet. E/A-Wartezeiten innerhalb einer Applikationknnen durch andere rechenbereite Threads der Applikation genutzt werden.Dagegen gewinnen CPU-dominierte Applikationen durch die Parallelisierungmittels Threads weniger an Performanz (falls nur eine CPU zur Verfgungsteht).

Threads ermglichen bei einem Multiprozessor-Rechensystem echte Paralleli-tt innerhalb einer Applikation.

Prozess vs. Thread

Prozesse und Threads haben unterschiedliche Zielsetzungen:

Prozesse gruppieren Ressourcen,

Threads sind Aktivittstrger, die zur Ausfhrung einer CPU zugeteiltwerden.

Threadspezifische InformationJeder Thread umfasst eine Reihe von Informationen, die seinen aktuellenZustand charakterisieren:

Befehlszhler, aktuelle Registerwerte, Keller, Ablaufzustand des Thread.

Prozessspezifische InformationDie nachfolgende Information/Ressourcen wird von allen Threads einesProzesses geteilt. Jeder Thread des Prozesses kann sie verwenden bzw. daraufzugreifen.

Adressraum, globale Variable, offene Dateien, Kindprozesse (z.B. erzeugtmit fork), eingetroffene Alarme bzw. Interrupts, Verwaltungsinformation

Beispiel: Web-Server

Ein Prozess kann mehrere Threads umfassen, die unterschiedliche Aufgaben ber-nehmen. Beispielsweise kann ein Web-Server einen Verteiler-Thread ("dispat-cher") und mehrere Server-Threads ("worker-thread") umfassen.

23

Schlichter, TU Mnchen 3.2. SYNCHRONISATION

Web-Serverprozess

Benutzer

Adressraum

Betriebssystem

Verteiler-

Thread

Server-

Thread

Netzwerk-Verbindung

Anforderung

Auf diese Weise ist es mglich den Server als eine Menge von sequentiellenThreads zu realisieren. Der Verteiler-Thread ist eine unendliche Schleife, die dieSchnittstelle fr den Eingang von Service-Anforderungen darstellt.

Der Verteiler-Thread dient zur Annahme von Service-Anforderungen und gibtsie weiter an einen der Server-Threads zur Bearbeitung.

Alle Server-Threads nutzen den gemeinsamen Web-Cache.

3.2 Synchronisation

Eine wichtige Systemeigenschaft betrifft die Synchronisation paralleler Ereignis-se. Mehrere Prozesse (oder Threads) konkurrieren um eine gemeinsame Ressour-ce (CPU), oder greifen auf gemeinsame Daten zu.

3.2.1 Beispiel: gemeinsame Daten

P1 und P2 sind nebenlufige Prozesse, die in einem Multiprozessorsystem parallelablaufen. Die Variable x ist gemeinsame Variable. Prozess P1 luft auf CPU 0mit Prozess P2 auf CPU 1 gleichzeitig ab. Das Problem ergibt sich auch beiquasiparallelem Ablauf (zeitliche Verschrnkung der Arbeit der Prozesse). Z seiein Zeitpunkt nach Ausfhrung der Aktionen A und B. Welchen Wert hat x zumZeitpunkt Z?

24


Das Ergebnis des Ablaufs kann je nach zeitlichem Ablauf x = 1, 2, 3 sein.

Der grundlegende Nichtdeterminismus der Nebenlufigkeit wegen der Asynchro-nitt schlgt hier auf die Ergebnisse der Prozesse durch.

int x; x = 0

Prozess P1 Prozess P2

A: x = x + 1

B: x = x + 2

Zeitpunkt Z

Mgliche Ablufe

Das Ergebnis ist vom zeitlichen Ablauf abhngig. Es sind folgende Flle mglich:

Fall 1P1 liest x = 0, erhht, speichert x = 1;P2 liest x = 1, erhht, speichert x = 3; => Wert von x = 3

Fall 2P2 liest x = 0, erhht, speichert x = 2;P1 liest x = 2, erhht, speichert x = 3; => Wert von x = 3

Fall 3P1 und P2 lesen x = 0;P1 erhht, speichert x = 1;P2 erhht, speichert x = 2; => Wert von x = 2

Fall 4P1 und P2 lesen x = 0;P2 erhht, speichert x = 2;P1 erhht, speichert x = 1; => Wert von x = 1

25


Verhinderung des Nichtdeterminismus nur dadurch mglich, dass man garantiert,dass die Vernderung von x in den beiden Prozessen unter wechselseitigemAusschluss (engl. mutual exclusion) erfolgt.

Der Zugriff auf gemeinsame Ressourcen, z.B. auf gemeinsame Variable, musskoordiniert werden. Bei exklusiven Ressourcen wird die Nutzung sequentialisiert.

Prozess P1:

main () {

.......

region x do

x = x + 1:

end region

........

}

Prozess P2:

main () {

.......

region x do

x = x + 2:

end region

........

}

3.2.2 Synchronisierungskonzepte

Ziel: Einfhrung wichtiger Realisierungskonzepte zur Synchronisierung parallelerAblufe. Dazu Konkretisierung des Prozessbegriffs.

Anforderungen fr wechselseitigen Ausschluss

Folgende Anforderungen sind an eine Realisierung des wechselseitigen Aus-schlusses (w.A.) zu stellen:

Die kritischen Abschnitte der Prozesse sind wechselseitig auszuschlieen. Eine Realisierung des w.A. darf nicht von einer Annahme ber die Reihenfolge,

in der die Prozesse ihre kritischen Abschnitte ausfhren, abhngen.

Eine Realisierung des w.A. darf nicht von Annahmen ber die Ausfhrungszeitder Prozesse abhngen.

Unter der Annahme, dass Prozesse nach endlicher Zeit ihre kritischenAbschnitte wieder verlassen, muss gelten, dass kein Prozess einen anderenProzess unendlich lange daran hindern darf, seinen kritischen Abschnittauszufhren.

26


Jede Realisierung des w.A. bentigt eine Basis, mit festgelegten atomaren, d.h.nicht teilbaren Operationen.

Konzepte fr wechselseitigen Ausschluss

UnterbrechungssperreDer Ablauf des Prozesses darf nicht unterbrochen werden.

In Ein-Prozessorsystemen (1 CPU) kann es ausreichend sein, mit Enable undDisable Interrupt Operationen dafr zu sorgen, dass der Prozess, der einenkritischen Abschnitt ausfhrt, dabei nicht unterbrochen wird.

Realisierung mit Unterbrechungssperre ist ntzlich fr den Betriebssystem-kern, aber sollte nicht fr allgemeine Benutzerprogramme zur Verfgung ste-hen.

Test-and-Set OperationenTest-and-Set Operationen (Test-And-Set-Lock, TSL) erlauben auf Hardware-Ebene (Maschinenbefehl) das Lesen und Schreiben einer Speicherzelle alsatomare Operation.

Semantik eines Test-and-Set-BefehlsDie Instruktion liest den Inhalt eines Speicherwortes in ein Register undschreibt einen Wert ungleich Null an die Adresse dieses Wortes. Diese beidenOperationen werden als atomare, unteilbare Sequenz ausgefhrt.

Sei a die zu untersuchende Speicherzelle; der Wert 1 in der Speicherzellekann dahingehend interpretiert werden, dass der Zugang in den kritischenBereich nicht mglich ist.

Befehl "TSL R, a" entspricht dannRegister R = inhalt von a;a = 1

Falls R = 1 ist, ist der kritische Bereich bereits belegt, andernfalls war erfrei und er wurde vom ausfhrenden Prozess belegt.

Problem: wie Atomaritt bei Rechensystem mit mehreren CPUs gewhr-leistet? Lsung: Die CPU, die die TSL-Instruktion ausfhrt, blockiert den

Speicherbus, um andere CPUs (Multi-Prozessorumgebung) daran zuhindern, auf die Speichereinheit zuzugreifen.

27


Dienste mit passivem WartenUnterscheidung zwischen

aktivem Warten: Prozess muss periodisch selber prfen, ob die Vorausset-zungen zum Weiterarbeiten erfllt sind.

passivem Warten: Prozess wird in Warte-Zustand versetzt und aufgeweckt,wenn das Ereignis, auf das er wartet, eingetreten ist.

Methoden oder Dienste, so dass unter Mithilfe des Betriebssystems einProzess in den Zustand wartend bergefhrt wird.

beim Eintreten eines passenden "Weckereignisses" wird der Prozessvom Betriebssystem vom Zustand wartend in den Zustand rechenbereitbergefhrt.

Beispiel: Java wait und notify.

Semaphor-KonzeptDas Semaphor-Konzept ermglicht die Realisierung des w.A. auf einem h-heren Abstraktionslevel als die bereits angesprochenen Hardwareoperationen.Zur Realisierung wird aber auf diese wieder zurckgegriffen. Realisierung vonSemaphoren mit aktivem und passivem Warten mglich.

Monitor-KonzeptDas Monitor-Konzept basiert auf der Idee, die in einem kritischen Bereichbearbeiteten Daten zusammen mit den darauf definierten Zugriffsoperationenin einer sprachlichen Einheit - dem Monitor - zusammenzufassen.

soll Probleme, wie sie bei der Programmierung von Semaphoren auftreten,vermeiden.

zu einem Zeitpunkt hchstens ein Prozess innerhalb des Monitors aktiv.

28


Initialisierungscode

Operationen

Gemeinsame Daten

Warte

schlange

Definition von Bedingungsvariablen zur Spezifikation anwendungsspezifi-scher Bedingungen.

Operationen auf Bedingungsvariable cond

cond.wait(): Prozess wird wartend gesetzt.

cond.signal(): ein wartender Prozess wird aktiviert.

3.2.3 Semaphore

Semaphore wurden 1968 von Dijkstra eingefhrt. Ein Semaphor (Signalmast) isteine ganzzahlige Koordinierungsvariable s, auf der nur die drei vordefiniertenOperationen (Methoden) zulssig sind:

Initialisierung,Prolog P (kommt von protekt),Epilog V (kommt von vrej).

Operationen

Die Operationen P und V sind atomar; sie sind unteilbar und sie werdenwechselseitig ausgeschlossen ausgefhrt.

Sei s die Koordinierungsvariable, dann sind die P und V Operationen wienachfolgend definiert.

Die Operation mssen mit Hilfe von Systemdiensten so realisiert werden, dasssie wechselseitig ausgeschlossen ausgefhrt werden. Vorsicht: hier gibt es keineganz einheitliche Definition in der Literatur fr die beiden Operationen. MglicheRealisierung auf Hardware-Ebene mittels des Test-and-Set Maschinenbefehls.

29


Informelle Charakterisierungpublic void P (int s) {

s = s - 1;if ( s < 0 ) { Prozess in die Menge der bzgl. s wartendenProzesse einreihen }

}

public void V (int s) {s = s + 1;if ( s 0 ) { fhre genau einen der bzgl. s wartendenProzesse in den Zustand rechenwillig ber }

}

Binres Semaphor: die Kontrollvariable s nimmt nur boolesche Werte an.man spricht auch von Mutex.

Mutex in PosixEin Posix Mutex ist als binres Semaphor eine einfache Sperre, die dieNutzung gemeinsamer Ressourcen absichert.

pthread_mutex_init(mutex) initialisiert und konfiguriert ein Mutex.pthread_mutex_lock(mutex) entspricht der P-Operation; sperrt einMutex.pthread_mutex_unlock(mutex) entspricht der V-Operation; gibt einMutex frei.

Mutex Objekte und Semaphore mit Integer Werten stehen auch in Windowszur Verfgung.

Einsatz von Semaphoren

Notation: Zur Vereinfachung gehen wir im Folgenden von einem vordefiniertenTyp semaphor(int s) aus, der die P und V Operationen als vordefinierte,atomare Methoden anbietet. Semaphor-Objekte werden als Instanzen bezglichdes Typs semaphor erzeugt, wobei bei der Instantiierung das Semaphor mit demParameter s initialisiert wird.

Zugang zu kritischen AbschnittenRealisierung der kritischen Abschnitte von Prozessen, in denen auf eineexklusiv benutzbare Ressource X zugegriffen wird:

1. Definition eines Semaphor-Objekts wa: semaphor(1), d.h. Initialisierung derKontrollvariable des Semaphor-Objekts wa mit 1.

30


2. Klammern der kritischen Abschnitte, in denen auf die Ressource Xzugegriffen wird, mit P und V Operationen:

wa.PCode mit Zugriffen auf Xwa.V

Die Anforderungen an Lsungen des wechselseitigen Ausschlusses sind mitdem Semaphor-Konzept aus folgenden Grnden erfllt:

Wechselseitiger Ausschluss fr alle kritischen Abschnitte. Aufgrund derInitialisierung der Koordinierungsvariablen mit 1 kann sich stets nur einProzess in einem kritischen Abschnitt befinden.

keine Reihenfolge-Annahmen. keine Ausfhrungszeit-Annahmen. kein Verhungern.

Beispiel Erzeuger-Verbraucher

Im Modellierungsteil wurde das Erzeuger-Verbraucher-Problem bereits kurzvorgestellt.

Der Erzeuger-Prozess E erzeugt Datenelemente und schreibt sie in einenPuffer W.Der Verbraucher-Prozess V liest Datenelemente aus dem Puffer undverarbeitet sie.Der Zugriff der beiden Prozesse auf den Puffer ist zu synchronisieren.

Lsung dieses Problems mittels Semaphor.

Variante 1Zugriff auf Puffer W erfolgt durch Semaphor wa: semaphor(1);

Erzeuger E:

while (true) {

produziere

wa.P

schreibe nach W

wa.V

}

Verbraucher V:

while (true) {

wa.P

entnimm aus W, falls Element da; sonst warte

wa.V

verarbeite

}

31


Problem: es kann eine Verklemmung auftreten, wenn der Verbraucher wa.Pausfhrt und warten muss, weil der Puffer kein Element enthlt.

Variante 2Einfhren eines zustzlichen Semaphors voll: semaphor(0), das die Datenele-mente im Puffer zhlt:

Erzeuger E:

while (true) {

produziere

wa.P

schreibe nach W

wa.V

voll.V

}

Verbraucher V:

while (true) {

voll.P

wa.P

entnimm aus W

wa.V

verarbeite

}

Fr den Erzeuger ergibt sich natrlich ein analoges Problem, falls der Puffer Wnur eine beschrnkte Kapazitt besitzt.

Variante 3Einfhren eines zustzlichen Semaphors leer: semaphor(n), das die Anzahl derfreien Elemente im Puffer zhlt:

Erzeuger E:

while (true) {

produziere Einheit;

leer.P;

wa.P;

schreibe Einheit nach W;

wa.V;

voll.V;

}

Verbraucher V:

while (true) {

voll.P;

wa.P;

entnimm Einheit aus W

wa.V

leer.V;

verarbeiteEinheit;

}

wa.semaphor(1); //kontrolliert den Zugang zum kritischen Bereich

voll.semaphor(0); //zhlt die Anzahl der Einheiten im Puffer

leer.semaphor(n); //zhlt die Anzahl der freien Pufferpltze

32


Beispiel Philosophenproblem

Zu den klassischen Synchronisationsproblemen zhlt das Problem der speisendenPhilosophen ("Dining Philosophers"). In einem Elfenbeinturm leben fnfPhilosophen. Der Tageszyklus eines jeden Philosophen besteht abwechselnd ausEssen und Denken. Die fnf Philosophen essen an einem runden Tisch, auf dem inder Mitte eine Schssel voller Reis steht. Jeder Philosoph hat seinen festen Platzan dem Tisch und zwischen zwei Pltzen liegt genau ein Stbchen. Das Problemder Philosophen besteht nun darin, dass der Reis nur mit genau zwei Stbchenzu essen sind. Darber hinaus darf jeder Philosoph nur das direkt rechts und dasdirekt links neben ihm liegende Stbchen zum Essen benutzen. Das bedeutet, dasszwei benachbarte Philosophen nicht gleichzeitig essen knnen.

1

04

3

2

0

1

2

3

4

Realisierung mit Semaphoren

Variante 1Fr eine Lsung des Philosophenproblems seien die folgenden 5 Semaphoredefiniert: stab_0, stab_1, ...., stab_4, wobei jedes der 5 Semaphore mit 1initialisiert ist. Jeder Philosoph j, mit j {0,...,4}, fhre den folgendenAlgorithmus aus:philosoph_j:

while (true) {Denken;stab_i.P; mit i = jstab_i.P; mit i = j + 1 mod 5Essenstab_i.V; mit i = jstab_i.V; mit i = j + 1 mod 5

}

33


Variante 2Nur vier Philosophen drfen gleichzeitig zu ihrem linken Stbchengreifen. Dies wird durch Einfhrung eines weiteren Semaphors tisch:semaphor(4), das mit 4 initialisiert wird, erreicht. Der "Anweisungsteil"jedes Philosophen wird zustzlich mit tisch.P und tisch.V geklammert.Es ergibt sich also folgende Lsung: Jeder Philosoph j, mit j {0,...,4} fhrtden folgenden Algorithmus aus:philosoph_j:

while (true) {Denken;tisch.Pstab_i.P; mit i = jstab_i.P; mit i = j + 1 mod 5Essenstab_i.V; mit i = jstab_i.V; mit i = j + 1 mod 5tisch.V

}

3.2.4 Synchronisierung von Java Threads

Java untersttzt synchronisierte Methoden.

public synchronized void methodname(...) { ... }

Eine synchronisierte Methode kann nur exklusiv von einem Java Thread betretenwerden.

Beispiel TakeANumber Class

Nur ein Thread kann zu einem Zeitpunkt eine Nummer ziehen

class TakeANumber {private int next = 0; //next place in linepublic synchronized int nextNumber() {

next = next + 1; return next;} //nextNumber

} //TakeANumber

34


public class Customer extends Thread {private static int number = 1000; //initial customer IDprivate int id;private TakeANumber takeANumber;public Customer(TakeANumber gadget) {

id = ++number;takeANumber = gadget;

} //Customer constructorpublic void run() {

try {sleep( (int)(Math.random() * 1000) );System.out.println("Customer "+id+" takes ticket " +takeANumber.nextNumber());

} catch ......} //run

} //Customer

public class Bakery {public static void main(String args[]) {

System.out.println("Starting Customer threads");TakeANumber numberGadget = new TakeANumber();.........for (int k = 0; k < 5; k++) {

Customer customer = new Customer(numberGadget);customer.start();

}} // main

} //Bakery

Java Monitor

Ein Monitor ist ein Java-Objekt, das synchronisierte Methoden enthlt.

Ein Monitor stellt sicher, dass nur ein Thread zur Zeit in einer dersynchronisierten Methoden sein kann. Bei Aufruf einer synchronisierteMethode wird das Objekt gesperrt.

Whrend das Objekt gesperrt ist, knnen keine anderen synchronisiertenMethoden des Objekts aufgerufen werden.

Kritische Abschnitte knnen in Java als Objekte mit den zugehrigensynchronisierten Methoden spezifiziert werden.

35

Schlichter, TU Mnchen 3.3. VERKLEMMUNGEN

3.3 Verklemmungen

Mit Verklemmung (engl. deadlock) bezeichnet man einen Zustand, in dem diebeteiligten Prozesse wechselseitig auf den Eintritt von Bedingungen warten, dienur durch andere Prozesse in dieser Gruppe selbst hergestellt werden knnen.Verklemmungen knnen durch die gemeinsame Verwendung von Ressourcen(synonym verwenden wir auch den Begriff Betriebsmittel), wie z.B. CPU,Arbeitsspeicher, E/A-Gerte, Dateien auftreten.

Der Austausch von Information ber gemeinsame Speicherbereiche ist einehufige Situation (speicherbasierte Prozessinteraktion), die bei unkorrekterVerwendung von Synchronisationsoperationen (z.B. P und V bei Semaphoren)leicht zu Verklemmungen fhren kann; siehe die Variante 1 des Erzeuger-Verbraucher Lsungsansatzes. Dieser Abschnitt skizziert nur die Anstze zurErkennung, Vermeidung und Verhinderung von Verklemmungen.

3.3.1 Allgemeines

Es lsst sich zeigen, dass die folgenden Bedingungen notwendig und hinreichenddafr sind, dass eine Verklemmung auftreten kann.

1. Die gemeinsam benutzbaren Ressourcen knnen nicht parallel genutzt werden,d.h. sie sind nur exklusiv benutzbar.

2. Die zugeteilten/belegten Ressourcen knnen nicht entzogen werden, d.h. dieNutzung ist nicht unterbrechbar.

3. Prozesse belegen die schon zugeteilten Ressourcen auch dann, wenn sie aufdie Zuteilung weiterer Ressourcen warten, d.h. wenn sie weitere Ressourcenanfordern.

4. Es gibt eine zyklische Kette von Prozessen, von denen jeder mindestens eineRessource belegt, die der nchste Prozess in der Kette bentigt, d.h. zirkulreWartebedingung.

3.3.2 Belegungs-Anforderungsgraph

Die Zuteilung/Belegung und Anforderung von Ressourcen kann man sichan einem Graphen, dem Belegungs-Anforderungsgraph, veranschaulichen. DieKnoten sind die Prozesse und Ressourcen, die Kanten spiegeln Belegungen undAnforderungen wider.

36


BeispielSeien P = {P1, ... , Pn} Prozesse und R= {R1, ... , Rm} Ressourcen, z.B. n = 3und m = 4. Beispiel eines Belegungs/Anforderungsgraphen.

P1 R1fordert

R2

belegt

P2

belegt

fordertR3

fordert

P3

belegt

R4belegt

3.3.3 Verklemmungs-Ignorierung

In vielen Systemen wird eine Vogel-Strau-Politik in bezug auf die Deadlock-problematik verfolgt, d.h. es werden keine Manahmen eingesetzt, sondern eswird gehofft, dass alles gut geht. In Unix wird diese Philosophie z.B. bei der Ver-waltung der Prozesstabelle verfolgt.

3.3.4 Verklemmungs-Erkennung

In der Praxis hufig angewendete Strategie: Verklemmungen in Kauf nehmen, sieerkennen und beseitigen.

Erkennungs-AlgorithmusAnsatz 1: Suche nach Zyklen im Belegungs/Anforderungsgraph.Ansatz 2: Prfen, ob es eine Reihenfolge fr die Ausfhrung der Prozesse gibt,so dass alle Prozesse terminieren knnen.

Vorgehen fr Ansatz 2

1. Starte mit Prozessmenge P, die alle Prozesse enthlt,

2. suche Prozess p aus P, dessen zustzliche Anforderungen im aktuellenZustand erfllbar sind,

3. falls gefunden, simuliere, dass p seine belegten Ressourcen wieder freigibt,

4. entferne p aus P und gehe zu 2

5. falls kein Prozess mehr in P, dann terminiert Suche: keine Verklemmung,

37


6. falls P 6= und in Schritt 2 kein Prozess mehr gefunden wird, dessenAnforderungen erfllbar sind, dann terminiert die Suche; P enthlt die Mengeder verklemmten Prozesse.

Auflsung einer Verklemmung in der Regel durch Abbruch einzelner Prozesse.

3.3.5 Verklemmungs-Verhinderung

Die Verhinderungssverfahren beruhen darauf, dass man durch die Festlegung vonRegeln dafr sorgt, dass mindestens eine der fr das Auftreten von Deadlocksnotwendigen Bedingungen nicht erfllt ist.

Festgelegte lineare ReihenfolgeBedingung "Zyklus tritt auf" in Belegungs-/ Anforderungsgraph darf nichterfllt werden. Dazu wird eine lineare Ordnung ber den Ressourcen definiert:R1 < R2 < ... Rm.

Die Prozesse drfen dann Ressourcen nur gem dieser Ordnung anfordern,

d.h. ein Prozess, der Ressource Ri belegt, darf nur Ressourcen Rj anfordern,fr die gilt: Rj > Ri.

Andere Mglichkeiten sind:a) Zuteilung aller bentigten Ressourcen zu einem Zeitpunkt.

b) zwangsweiser Entzug aller belegter Ressourcen, falls eine Ressourcen-Anforderung nicht erfllt werden kann.

c) Spooling: nur der Spooler Prozess hat als einziger die Ressourcezugeteilt; Zugriffe anderer Prozesse gehen ber diesen Prozess. Beispielist das Spooling von Druckauftrgen.

3.3.6 Verklemmungs-Vermeidung

Die Vermeidungsverfahren basieren auf der Idee,

die zuknftigen Betriebsmittelanforderungen von Prozessen zu analysieren(bzw. diese geeignet abzuschtzen) und

solche Zustnde zu verbieten (sie also zu verhindern), die zu Verklemmungenfhren knnten.

Ein Beispiel ist der Bankiers-Algorithmus, der 1965 von Dijkstra entwickeltwurde.

38


Veranschaulichung des Algorithmus

Veranschaulichung des Verfahrens anhand eines Bankenszenarios.

AusgangspunktIdee: Verwaltung von nur einer Ressourcen-Klasse, nmlich den Bankkrediten.

Bankier besitzt festen Geldbetrag und verleiht Geld an seine Kunden. Alle Kunden sind dem Bankier bekannt, jeder Kunde hat einen eigenen

maximalen Kreditrahmen, der kleiner als die zur Verfgung stehendeGeldmenge des Bankiers ist.

Bankier hat weniger Geld als die Summe dieser Kreditrahmen. Kunden knnen jederzeit Geld in der Hhe ihres jeweiligen Kreditrahmens

fordern, mssen aber ggf. in Kauf nehmen, dass der Bankier diese Forderungerst nach endlicher Zeit erfllt.

Aufgabe des BankiersVerleihen des Geldes so, dass jeder Kunde seine Geschfte in endlicher Zeitdurchfhren kann und Kunden mglichst parallel bedient werden.

Idee: Reihenfolge fr Kreditvergabe finden, so dass selbst bei denkbar un-gnstigsten Kreditforderungen die Durchfhrung aller Geschfte sicherge-stellt ist.

ungnstigster Fall: alle Kunden fordern Geld bis zu ihrem jeweiligen max.Kreditrahmen, ohne Kredite zurckzuzahlen.

Grobes Vorgehen1. falls ein Kunde (Prozess) eine Anforderung hat, die aktuell erfllbar ist,so teilt man das Geld (die Ressource) probeweise zu und2. untersucht fr den sich damit ergebenden Zustand, ob jetzt eineVerklemmung vorliegt, indem3. fr alle anderen Kunden von deren ungnstigsten Anforderungenausgegangen wird und4. ein Erkennungs-Algorithmus ausgefhrt wird.

Falls keine Verklemmung auftritt, kann die Zuteilung tatschlich erfolgen,anderenfalls knnte bei einer Zuteilung ein Deadlock auftreten (muss abernicht), weshalb die Anforderung nicht erfllt wird.

39


BeispielAusgangspunkt ist die folgende Situation der vier Kunden A, B, C, D (Einheitenjeweils in Tausend Euro):

Kunde aktueller Kredit max. KreditrahmenA 1 6B 1 5C 1 4D 4 7

Es seien noch 3 Einheiten (Tausend Euro) in der Bank als Kredit verfgbar.

Annahme: Kunde C fordere eine weitere Einheit als Kredit an. DieseAnforderung wird probeweise zugeteilt und mndet nicht in einem Deadlock,da zuerst C (max noch 2 Einheiten bis Kreditrahmen) bedient werden kann.

Wenn C seine Einheiten wieder zurckgezahlt hat, knnen B oder D undschlielich A bedient werden.

40


3.3.7 Vergleich der Anstze

Ansatz Verfahren Vorteile NachteileErkennung periodischer

Aufruf desErkennungsAlgorithmus

Prozesserzeugungwird nicht verz-gert; erleichtertinteraktive Reak-tion

Verlust durch Ab-bruch

Verhinderung feste Reihefolgebei der Zuteilung

keine Verklem-mungsanalysezur Laufzeitnotwendig; ber-prfung whrendbersetzung

keine inkremen-tellen Anfragenfr Ressourcenmglich

Zuteilung allerRessourcen aufeinmal

keine Premp-tion (Entzug)von Ressourcennotwendig; gutfr Prozesse miteinzelner Aktivi-ttsphase (singleburst)

ineffizient;verzgert Pro-zesserzeugung;Bedarf fr Res-sourcen mussbekannt sein

Vermeidung Bankiers-Algorithmus

keine Premp-tion (Entzug)von Ressourcennotwendig

zuknftigerBedarf mussbekannt sein;Prozesse knnenlngere Zeitblockiert werden

41

Kapitel 4

Prozess- und Prozessorverwaltung

Ein Prozess ist der Ablauf eines Programms in einem Rechensystem. DieserAblauf ist eine Verwaltungseinheit im jeweiligen Betriebssystem.

4.1 Fragestellungen

Dieser Abschnitt gibt eine kurze Einfhrung in eine der wichtigen Verwaltungs-aufgaben eines Betriebssystems:

Verwaltung von Prozessen. Verwaltung des Prozessors, d.h. Zuteilung der CPU an rechenbereite Prozesse

(Scheduling).

Unterbrechungskonzept.

4.2 Prozessverwaltung

Dieser Abschnitt behandelt das Prozesskonzept, Datenstrukturen zur Beschrei-bung des aktuellen Prozesszustandes sowie Dienste zum Aufruf von Systemfunk-tionen.

Prozesse reprsentieren eine Aktivitt; sie haben ein Programm, Eingaben,Ausgaben und einen Zustand.

42

Schlichter, TU Mnchen 4.2. PROZESSVERWALTUNG

4.2.1 Prozesskonzept

Wir unterscheiden Benutzerprozesse, die Anwendungsprogrammen in Ausfh-rung entsprechen, und Systemprozesse, die Programme/Dienste des Betriebssy-stems durchfhren.

a) Jeder Prozess besitzt einen eigenen Prozessadressraum.b) Spezielle Systemprozesse sind die Dmonen (engl. daemon); das sind

Hilfsprozesse, die stndig existieren, die meiste Zeit aber passiv sind.

Dienste der Prozessverwaltung

Die Prozesse werden durch das Betriebssystem verwaltet.

Auslsende Ereignisse fr die Erzeugung eines ProzessesInitialisierung des Systems.

Systemaufruf zum Erzeugen eines Prozesses durch einen anderen Prozess.

Benutzeranforderung zum Starten eines neuen Prozesses (Start einerApplikation).

Auslsung eines Stapelauftrags (Batch Job).

Formen der Terminierung von ProzessenNormale Beendigung (freiwillig).

Vorzeitige Beendigung bei einem durch den Prozess selbst erkannten Fehler(freiwillig).

Vorzeitige Beendigung bei einem katastrophalen Fehler, erkannt durch dasBS (unfreiwillig).

Terminierung durch einen anderen Prozess (unfreiwillig).

Prozess-Auswahl, Strategien zur Prozessorzuteilung: Scheduling. Prozessor-Anbindung; Dispatching.

Prozesskontrollblock

Jeder Prozess muss als eine Verwaltungseinheit beschrieben sein. Ein Prozesswird durch seinen Prozess-Kontext und dieser durch den Prozesskontrollblock(PCB) beschrieben. Ein PCB wird meist programmiersprachlich als Verbund(struct) spezifiziert. Ein PCB (process control block) enthlt i.d.R. folgendeInformationen:

43


eindeutiger Name, z.B. fortlaufende Nummerierung des Prozesses (z.B. pid inUnix)

Name des Benutzers, dem der Prozess zugeordnet ist der momentane Prozesszustand (wartend, rechnend, rechenwillig, ...) falls der Prozess rechnend ist, Angabe der zugeordneten CPU falls der Prozess wartend ist, eine Spezifikation des Ereignisses, auf das der

Prozess wartet (z.B. Adresse eines Semaphors).

die Ablaufprioritt des Prozesses die Inhalte der programmierbaren Register (die Anzahl ist abhngig von der

jeweiligen CPU-Architektur), z.B. Kellerpointer.

die Inhalte der Register, in denen die Anfangsadresse und Lnge der pro-zessspezifischen Speicherabbildungstabellen enthalten sind (virtuelle Adressie-rung).

das Programmstatuswort (PSW).Beispiele fr dem Inhalt des PWSs sind derAblaufmodus (Benutzer- oder Systemmodus), die momentane Ablaufprioritt,die Adressierungsart im Benutzermodus (virtuelle oder direkte Adressierung)und die Ergebnisse der letzten Vergleichsoperation auf Maschinenebene(sogenannte Condition-Code Register, z.B. das N-Register (Ergebnis der letztenOperation negativ).

PCB unter Linux ist durch die Struktur task_struct spezifiert; definiert unterinclude/linux/sched.h .

Prozesslisten

Die Prozesse werden in Zustandslisten verwaltet, die als verkettete Liste der PCBsrealisiert sind.

fr E/A-Gerte (z.B. Platte, Terminal) existiert i.d.R. jeweils eine eigeneWarteschlange, die die PCBs der wartenden Prozesse enthlt.

44


Rechnend

Rechenwillig

Wartend

Prozessidentifikation

Registerzustand

Scheduling Information (z.B.

Prioritt)

Adressrauminformation

Sonstiges

nchster PCB

Ready-Queue

Prozesskontrollblock PCB

Zustandsmodell

Das Prozess-Zustandsmodell unterscheidet neben den bereits vorgestelltenZustnden rechenwillig, rechnend, wartend auch den Zustand ausgelagert.Letzterer Zustand tritt ein, wenn der Adressraum aufgrund Speichermangels ausdem Arbeitsspeicher auf den Hintergrundspeicher verlagert wird ("swapping").

rechnend

wartend

rechenwillig

ausgelagert

ready

assign

block

add retire

resign

swap outswap in

Zustandsbergnge sind:

add: ein neu erzeugter Prozess wird zu der Menge der rechenwilligen Prozessehinzugefgt;

assign: als Folge eines Kontextwechsels wird dem Prozess die CPU zugeordnet;

45


block: aufgrund eines EA-Aufrufs oder einer Synchronisationsoperation wird derProzess wartend gesetzt;

ready: nach Beendigung der angestoenen Operation wechselt der Prozess in denZustand rechenwillig; er bewirbt sich erneut um die CPU;

resign: dem rechnenden Prozess wird die CPU entzogen; er bewirbt sichanschlieend erneut um die CPU;

retire: der aktuell rechnende Prozess terminiert;

swap out: der Prozess wird auf die Festplatte ausgelagert;

swap in: der Prozess wird von der Festplatte in den Arbeitsspeicher geladen.

Prozesserzeugung

Ein Prozess kann andere Prozesse erschaffen. Diese sind die Kindprozesse (childprocess) und der Erschaffer ist der Vater (parent process). Vater

kann auf Beendigung von Kind warten, oderparallel weiterlaufen.

Prozesserzeugung: 2 VorgehensweisenWindows NT: Vaterprozess veranlasst eine Reihe von Systemaufrufen, diedas Kind entstehen lassen.

Unix: Vater klont sich mit Systemaufruf fork(); Kind ndert selbst seinAufgabe.

Unix ProzesserzeugungAufruf von fork() fhrt zu einem fast exakten Duplikat des Vaterprozesses.Unterschiede sind

unterschiedlicher process identifier (PID)

der Ergebniswert von fork()Vater: PID des KindprozessesKind: 0

Beispielprogramm#include

46


int main(int argc, char *argv[]) {char *myname = argv[1];int cpid = fork();if cpid == 0 {

printf("The child of %s is %d\n", myname, getpid());.......return (0);

} else {printf("My child is %d\n", cpid);/* wird vom Vaterprozess durchlaufen */.....return(0);

}}

Kind hat vieles mit dem Vater gemeinsam:liest dieselben Dateien, gleicher Benutzername, benutzt dieselben Daten

Unix Kind fngt mit dem Code des Vaters an und ndert sich dannSystemaufruf exec(): ersetzt das Programmbild des Vaters mit einemanderen.

Beispielprogramm fr exec#include int main(int argc, char *argv[]) {

char *myname = argv[1];int cpid = fork();if cpid == 0 {

int rc;rc = execl("/bin/ls", "ls", "-l", (char *) 0);printf("Fehler bei execl Aufruf: %d\n", rc);exit(1)

} else {/* wird vom Vaterprozess durchlaufen */

}}

PrinzipablaufMit der Systemfunktion wait wartet der Vaterprozess auf den Kindprozess.

wait vor Beendigung des Kindes: Vater ist blockiert.wait nach Beendigung des Kindes: Kind wird nach Beendigung zumZombieprozess.

47


Vater

forkVater

Kind

wait

exit

Vater

Vater

forkVater

Kind

wait

exit

Vater

Zombieprozess

Linux untersttzt den Systemaufruf clone() zur Erzeugung neuer Thread-Kopien.

Prozesse und Vererbung

Bei der Verwaltung von Vater-/Kindprozess sind eine Reihe von Entscheidungenzu treffen:

AusfhrungVaterprozess und Kind werden gleichzeitig ausgefhrt, oder

der Vaterprozess wartet darauf, dass das Kind beendet wird

RessourcenVater und Kind teilen sich alle Ressourcen.

Vater und Kind teilen sich einen Teil der Ressourcen.

Vater und Kind haben keine Ressourcen gemeinsam.

AdressraumDas Kind ist ein Duplikat des Vaters.

Das Kind fhrt durch automatisches Laden ein neues Programm aus (exec-Systemaufruf).

ThreadsDas Kind dupliziert alle Threads des Vaters.

Das Kind dupliziert nur den Thread des Vaters, der die fork-Operationausgelst hat.

48


4.2.2 Dispatcher

Aufgabe des Dispatchers: Realisieren der Zustandsbergnge zwischen rechnendund rechenwillig: Prozessor binden und entbinden. Dazu ist ein Kontextwechselerforderlich.

Kontextwechsel

CPU wird entzogen und einer anderen Aktivitt zugeteilt; ein Kontextwechsel isterforderlich, falls der rechnende Prozess P1 in den Zustand wartend oder z.B.durch Prozessorentzug in den Zustand rechenwillig bergefhrt wird.

Problemaktueller Ausfhrungskontext des Prozesses muss gesichert werden undKontext des nchsten rechenbereiten Prozesses muss geladen werden.

Achtung: je umfangreicher ein PCB ist, desto "teurer" sind Prozesswechsel,d.h. das Umschalten der CPU zwischen den Prozessen.

Threads

Threads haben einen sehr viel kleineren KontextUmschalten zwischen Threadsinnerhalb eines Prozesses sehr schnell, da Adressraum und andere Ressourcen(z.B. Dateien) gemeinsam genutzt werden.

4.2.3 Arbeitsmodi

Ziel fr den Betrieb von Rechensystemen: kontrollierter Zugriff auf Hardware-komponenten nur durch BS. Dadurch soll verhindert werden, dass Benutzer oderSoftwaresysteme Hardwarekomponenten unsachgem nutzen, und implizit an-dere nebenlufige Aktivitten schdigen.

Lsung: alle Zugriffe auf Hardware nur ber privilegierte Befehle zulssig;Frage: wer darf privilegierte Befehle ausfhrenAntwort: Prozesse in einemprivilegierten Modus.

Herkmmlich unterscheidet man zwischen dem Benutzer- (engl. user mode) unddem Systemmodus (engl. kernel mode).

Benutzermodus

49


Es sind nur die nicht privilegierten Befehle verfgbar. Damit ist der Zugriff aufProzessadressraum und unkritische Register, wie Befehlszhler, Indexregistermglich. Benutzerprozesse werden im Benutzermodus ausgefhrt. KritischeRegister, ber die der Kontext eines Prozesses beeinflusst werden kann(z.B. Ablaufprioritt, Arbeitsmodus) knnen nur im Systemmodus verndertwerden. Wird versucht, einen privilegierten Befehl auszufhren, gibt es einenBefehlsalarm.

SystemmodusEs sind auch die privilegierten Befehle verfgbar (z.B. Anhalten der Maschine,Verndern der Ablaufprioritt). Die Dienste des Betriebssystemkerns werdenim Systemmodus ausgefhrt.

Nutzung der Hardware-Komponenten nur ber Dienste des BS: Aufruf einesBS-Dienstes ber spezielle Befehle: den Systemaufruf.

4.2.4 Systemaufrufe

Ein Systemaufruf ist eine Funktion, die von einem Benutzerprozess aufgerufenwird, um einen BS-Kerndienst aufzufhren.

1. Der Systemaufruf berprft die bergebenen Parameter und bildet darauseine Datenstruktur, um die Daten an den BS-Kern weiterzureichen.

2. Danach wird eine spezielle Instruktion, ein Software Interrupt (Trap), aus-gefhrt. Diese Instruktion identifiziert ber einen Operanden den gewnsch-ten Systemdienst.

3. Bei Ausfhrung der Trap-Instruktion wird der Zustand des Benutzerprozes-ses gerettet und es findet ein Wechsel in den Systemmodus statt.

BeispielLesen von Daten aus einer Datei und Kopieren in eine andere Datei. Dabeitreten die folgenden Systemaufrufe auf:

(1) Schreiben des Prompts auf Bildschirm: Angabe der Dateinamen(2) Lesen der Tastatureingabe (bzw. Analoges bei Mouse-Eingabe)(3) ffnen der zu lesenden Datei (open)(4) Erzeugen der neuen Datei(5) ggf. Fehlerbehandlung: Nachricht auf Bildschirm(6) Schleife: Lesen von Eingabedatei (ein Systemaufruf) und schreiben in

zweite Datei (auch Systemaufruf)(7) Schlieen beider Dateien(8) Ausgabe auf Bildschirm

50


Durch die Verwendung von Laufzeitroutinen ergibt sich eine hhere Abstrakti-onsebene Aufruf einer Routine, die die notwendigen Systemaufrufe durch-fhrt.

4.2.5 Realisierung von Threads

Es existieren zwei grundlegende Anstze, Threads in einem Rechensystemzu realisieren: im Benutzer-Adressraum (Benutzermodus) oder im System-Adressraum (Systemmodus).

im Benutzer-Adressraum

Der BS-Kern verwaltet nur single-threaded Prozesse.

Prozess Thread

Laufzeit-

system

Benutzer

Adressraum

(Benutzermodus)

BS-KernSystem

Adressraum

(Systemmodus)

Prozess-

tabelleThread

tabelle

Threads werden durch Laufzeitsystem im Benutzeradressraum verwaltet. EineThread-Tabelle speichert Informationen (Register, Zustand, etc.) ber Threadspro Prozess.

Prozessorzuteilung im BS-Kern erfolgt an Prozesse. Laufzeitsystem bestimmt,welcher Thread rechnend gesetzt wird.

Problem: Systemaufruf eines Threads blockiert die anderen Threads desProzesses.

Problem: wie wird einem Thread die CPU entzogen?

51

Schlichter, TU Mnchen 4.3. PROZESSORVERWALTUNG

im System-Adressraum

Neben den Prozessen werden im BS-Kern auch alle Threads verwaltet.

Prozess Thread

Benutzer

Adressraum

(Benutzermodus)

BS-KernSystem

Adressraum

(Systemmodus)

Prozess-

tabelle

Thread

tabelle

Thread-Tabelle speichert Informationen (Register, Zustand, etc.) ber Threads. Prozessorzuteilung im BS-Kern erfolgt an Threads. Der Systemaufruf eines Threads blockiert nicht die anderen Threads des

Prozesses.

4.3 Prozessorverwaltung

Eine wesentliche Aufgabe der Prozessorverwaltung besteht darin zu entscheiden,welcher der um den bzw. die Prozessor(en) konkurrierenden Prozesse (bzw.Threads) zu einem Zeitpunkt an den bzw. die Prozessor(en) gebunden wird. Dazusteht die BS-Komponente Scheduler zur Verfgung.

Prozessablauf besteht aus einer Sequenz von alternierenden CPU- und E/A-Perioden.

Zeitliche Verschrnkung der Prozessbearbeitung bei einer CPU.

52


Zeit

Prozess A

BS-Kern

Prozess B

A hat CPU

Unterbrechung

BS-Kern

hat CPU

Zuweisung

CPU an B

Unterbrechung

A hat CPU

B hat CPU

BS-Kern

hat CPU

Zuweisung

CPU an A

4.3.1 Kriterien

Der Scheduler whlt aus der Menge der rechenwilligen Prozesse den nchstenauszufhrenden Prozess aus. Es existieren unterschiedliche Verfahren die von derjeweiligen Prozessorverwaltungsstrategie abhngen. Mgliche Leistungskriterienfr ein Schedulingverfahren:

Fairness. Effizienz, Prozessorauslastung. Antwortzeit fr interaktive Benutzer (Dialogverarbeitung). Wartezeit, insbesondere fr Batch-Jobs (Stapelverarbeitung). Ausfhrungszeit, d.h. Zeitspanne von Auftragsbeginn bis Auftragsende. Abschlusszeit, insbesondere fr Realzeitsysteme. Durchsatz, Anzahl der Auftrge pro Zeiteinheit.

Kriterien der Betriebsarten

Die Ziele der Schedulingverfahren hngen von der Umgebung und denBetriebsarten des Rechensystems ab.

53


Alle SystemeFairness - jeder Prozess bekommt Rechenzeit der CPU.

Balance - alle Teile des Systems sind ausgelastet.

Policy Enforcement - Scheduling Policy wird nach auen sichtbardurchgefhrt.

StapelbetriebDurchsatz - maximiere nach Auftrge pro Zeiteinheit.

Ausfhrungszeit - minimiere die Zeit von Start bis zur Beendigung.

CPU-Belegung - belege CPU konstant mit Auftrgen.

Dialogbetrieb - interaktive SystemeAntwortzeit - antworte schnellstmglich auf Anfragen.

Proportionalitt - Erwartungshaltung der Nutzer bercksichtigen.

EchtzeitsystemeAbschlusszeit - kein Verlust von Daten.

Vorhersagbarkeit - Qualittsverlust bei Multimedia vermeiden.

4.3.2 Scheduling-Strategien

Es werden zwischen zwei Klassen unterschieden: nicht-unterbrechende (nonpre-emptive) und unterbrechende Strategien (preemptive).

nicht unterbrechend: Scheduling nur dann mglich, wenn der rechnendeProzess blockiert wird oder wenn er terminiert, d.h. Prozess behlt CPU biser sie selber abgibt.

Beispiel: Microsoft Windows 3.x; unterbrechende Strategien erst abWindows 95

unterbrechend: Unterbrechung beim Eintreten von speziellen Ereignissen,u.a. Eintreffen eines Prozesses mit hherer Prioritt oder Prozess geht inWartezustand.

54


Zeitscheibenstrategie

Die Zeitscheibenstrategie (Round Robin) ist unterbrechend. Ziel ist diegleichmige Verteilung der Rechenzeit auf rechenwillige Prozesse. Round Robinist eine weit verbreitete preemptive Schedulingvariante. Das Verfahren ordnetjedem rechenwilligen Prozess ein definiertes Zeitquantum (Zeitscheibe) zu. In 4.3BSD Unix betrgt z.B. die Zeitscheibe 100 ms. Nach dem Kontextwechsel ist derProzess entweder bis zum Ablauf des Zeitquantums oder bis zum Auftreten einerblockierenden Systemfunktion im Besitz der CPU. Alle rechenwilligen Prozessewerden in einer FIFO-Warteschlange verwaltet. Nach Ablauf der Zeitscheibe wirdder Prozess am Ende der FIFO-Warteschlange eingereiht.

Es werden die Prozesse an den Prozessor jeweils fr ein festgelegtesZeitquantum q gebunden und sptestens nach dem Ablauf dieser Zeitspannewird den Prozessen der Prozessor wieder entzogen.

zyklisches Bedienen der Prozesse (Round Robin). Ready-Queue (Liste der rechenwilligen Prozesse) als zyklische Warteschlange

realisiert.

Wahl des Zeitquantums:falls q zu klein: viele unproduktive Kontextwechsel.falls q zu gro: Round Robin wird zu einem reinen FCFS Scheduling(First Come First Served), da die Wahrscheinlichkeit fr einen Aufruf einesblockierenden Systemdienst steigt.Typische Werte fr q: 10 bis 100 Millisekunden.

Fr q = 100 ms gilt bei 1 MIPS Maschine (Million Instructions/Second): ca.100.000 Instruktionen/q.

Prioritten

Diese Strategie ist i.a. unterbrechend. Sie basiert darauf, an die Prozesse Priorit-ten zu vergeben. Die Priorittenvergabe kann dabei statisch oder dynamisch sein.Die Priorittenstrategie kann unterbrechend und nicht-unterbrechend sein. Im er-sten Fall wird der Ablauf eines Prozesses unterbrochen, wenn ein anderer Prozessmit hherer Prioritt rechenwillig wird. Im zweiten Fall behlt der Prozess dieCPU solange bis er entweder eine blockierende Systemfunktion aufruft oder dieCPU freiwillig abgibt.

Prioritten sind i.a. ein festgelegter Zahlenbereich, z.B. 0, ..., 7.

55


Statische Priorittenvergabejeder Prozess besitzt fr die Dauer seiner Existenz eine feste Prioritt.

Problem: Gefahr des Verhungerns von Prozessen mit niedriger PriorittLsung: Erhhung der Prioritt von lange wartenden Prozessen, d.h.dynamische Prioritten.

Dynamische Priorittenvergabedie Prioritten der Prozesse knnen sich dynamisch verndern, d.h. sie werdenin gewissen Zeitabstnden neu berechnet.

Idee: lange Wartezeiten bercksichtigen (Erhhen die Prioritt).Prozesse mit groem CPU-Verbrauch sinken in Prioritt.E/A-intensive Prozesse steigen in Prioritt (damit E/A-Gerte und CPUparallel genutzt werden).

Zeitscheibenstrategien und Priorittenvergabe knnen zu effizienten Verwal-tungsstrategien kombiniert werden.

Windows XP SchedulingWindows XP nutzt eine Prioritten-basierte, unterbrechende Strategie. Pro-zess/Thread mit hchster Prioritt wird ausgefhrt, bis

er terminiert, oderer seine Zeitscheibe ausgeschpft hat, odereine Blockierung (Systemaufruf, E/A) auftritt.

Es werden Prioritten von 0 - 31 unterschieden, die in verschiedene Klasseneingeteilt werden

Echtzeit hoch bernormal

normal unternormal

idle

zeit kri-tisch

31 15 15 15 15 15

hchste 26 15 12 10 8 6bernormal

25 14 11 9 7 5

normal 24 13 10 8 6 4unternormal

23 12 9 7 5 3

niedrigst 22 11 8 6 4 2idle 16 1 1 1 1 1

56


First-Come First-Served

Dieses nicht-unterbrechende Verfahren (FCFS) teilt einen Prozessor in derReihenfolge des Auftragseingangs zu. Ready-Queue wird als FIFO-Listeverwaltet; Verfahren einfach zu realisieren.

Ein Kontextwechsel findet nur statt, wenn der Prozess eine blockierendeSystemfunktion aufruft oder der Prozess die CPU freiwillig abgibt.

Es kann eine hohe CPU Auslastung erreicht werden. Problem: Durchschnittliche Wartezeit ist hoch.

Beispiel: Prozesse P1,P2,P3 kommen nahezu gleichzeitig zum Zeitpunkt 0an;Dauer ihrer Berechnungszeiten: P1: 24 ms, P2: 3ms, P3: 3ms;bei Reihenfolge P1, P2, P3: mittlere Wartezeit: (0 + 24 + 27)/3 = 17 msbei Reihenfolge P2, P3, P1 mittlere Wartezeit (0+3+6)/3 = 3 ms

Shortest-Jobs-First

Dieses Verfahren (SJF) fhrt die Prozessorzuteilung in der Reihenfolge derwachsenden Rechenphasen ("CPU-Burst") zu, d.h. Prozess mit krzester, nchsterRechenphase erhlt Prozessor als nchster.

anwendbar, falls die Dauer der nchsten Rechenphase bis E/A-Befehl, Interruptetc. bekannt ist.

Beispiel: P1: 6ms, P2: 8ms, P3: 7ms, P4: 3msSchedule bei SFJ : P4, P1, P3, P2; Wartezeit: (3+16 +9 +0) /4 = 7 msbei FCFS: 10.25 ms (P1 vor P2 vor P3 vor P4)

Problem: Kenntnis ber die Bedienzeiten erforderlich. Fr Stapelbetriebgeeignet, da dort Information ber Rechenzeiten zur Verfgung stehen(Benutzer geben bei Batch-Jobs Rechenzeit an).

Fr interaktive Prozesse wird die Lnge der nchsten Rechenphase ("Burst")geschtzt:

Sn+1 = 1/nni=1

Ti

Ti = Ausfhrungszeit der i-ten Rechenphase.

57


Si = Schtzung fr die i-te Rechenphase.

S1 = Schtzung fr die erste Rechenphase.

Anpassung der Berechnung

Sn+1 = (1/n) * Tn + (n-1)/n * Sn

4.3.3 Thread Scheduling

Die Prozessorzuteilung von Threads hngt von deren Art der Realisierung ab.

User-Threads

Realisierung der Threads im Benutzeradressraum Kern hat keine Kenntnisbzgl. der Threads. BS-Scheduler whlt nur Prozess aus. Laufzeitsystem desProzesses whlt rechenwilligen Thread des Prozesses aus; es kann ein beliebiges Scheduling-Verfahren (siehe Seite 54) fr Prozesse verwendet werden.

Java Virtual Machines verwenden unterbrechendes Prioritten-Scheduling frThreads;

10 ist die hchste und 1 die niedrigste Prioritt;

Kernel-Threads

Realisierung der Threads im Systemadressraum BS-Scheduler whlt dennchsten auszufhrenden Thread aus.

a) Ist ausgewhlter Thread demselben Prozess zugeordnet wie der vorherrechnende Thread geringer Kontextwechsel.b) Ist ausgewhlter Thread nicht demselben Prozess zugeordnet wie dervorher rechnende Thread aufwendiger Kontextwechsel.

4.3.4 Mehrschichtiges Scheduling

Der Scheduler whlt einen der rechenwilligen Prozesse aus. Da diese aber u.U.nicht alle im Arbeitsspeicher vorliegen (Speicherknappheit) und ein Einlagerneines Prozesses von der Platte in den Arbeitsspeicher aufwendig ist, verfgenSysteme hufig ber ein Mehr-Schichten Scheduling.

58


Short-Term-Scheduler (CPU Scheduler)Auswahl eines geeigneten Prozesses aus der Ready-Queue; wird hufigaufgerufen; Verfahren siehe oben.

Long-Term-SchedulerAuswahl rechenwilliger neuer Auftrge (meist Jobs aus dem Hintergrundbe-trieb (batch)) und Einlagerung in den Arbeitsspeicher; Einfgen der Prozessein die Ready-Queue.

Graphische Darstellung

Long-term

Scheduler

neue

Auftrge

swap-in

CPU Scheduler

E/A-Warteschlange

Zeit-Interrupt-

Warteschlange

CPU fertig

E/A-Befehl

Zeitscheibe

abgelaufen

sleep-Befehl

Systemaufruf

Ready Queue

ausgeswappte

Prozesseswap-out

Ausfhrung im

BS-Kern

59


4.3.5 Echtzeit Scheduling

In Multimedia-Umgebungen treten die zu verarbeitenden kontinuierlichen Daten(Empfangen, Dekodierenen und Anzeigen von Videoframes) in bestimmten, meistperiodischen Zeitabstnden auf. Die Operationen auf diese Daten wiederholensich dabei immer wieder und sollen bis zu einem gewissen Zeitpunkt abgeschlos-sen sein. Prozesse in Multimedia-Anwendungen fhren oft zeitkritische Operatio-nen aus. Bzgl. des Scheduling existieren zwei gegenstzliche Ziele:

a) ein unkritischer Prozess sollte nicht dauerhaft blockiert werden, weilzeitkritische Prozesse eine Ressource gnzlich auslasten.b) zeitkritische Prozesse drfen nicht durch Scheduling-Verfahren (Round-Robin oder Prioritten) am zeitkritischen Fortschritt gehindert werden Einhaltung von Zeitvorgaben.

Zuordnung von Kenngren zu zeitkritischen ProzessenBereitzeit (ready time): frhestmglicher Ausfhrungsbeginn einerAktivitt.Frist (deadline): sptester Zeitpunkt fr die Beendigung einer Aktivitt.Ausfhrungszeit: worst-case Abschtzung fr das zur vollstndigenAusfhrung einer Aktivitt notwendige Zeitintervall.

Earliest Deadline First (EDF)Der Prozessor wird immer dem Prozess mit der am nchsten in derZukunft liegenden Frist zugeordnet. Es existieren die beiden Varianten: nicht-unterbrechend und unterbrechend.

nicht-unterbrechendEine Prozessorzuordnung bleibt bis der Prozess eine blockierende System-funktion aufruft oder freiwillig die CPU abgibt. Neue eintreffende Prozessemit krzeren Fristen werden erst beim nchsten Scheduling bercksichtigt.

unterbrechendDiese Variante fhrt einen Kontextwechsel durch, wenn ein Prozess mit einerkrzeren Frist rechenwillig wird.

Rate-Monotonic SchedulingRate-Monotonic Scheduling (RMS) ist fr periodische Prozesse; RMS ordnetPrioritten in Abhngigkeit von der Periode zu.

1) Prozesse mit der hchsten Frequenz (kleinste Periode) erhalten diehchste Prioritt.2) Prozesse mit der geringsten Frequenz (lngste Periode) erhalten dieniedrigste Prioritt.

60

Schlichter, TU Mnchen 4.4. UNTERBRECHUNGSKONZEPT

Auswahl der Prozesse anhand ihrer Prioritt. hochfrequente Prozesse werden minimal verzgert. Zerstckelung niederfrequenter Prozesse, da sie hufig wegen hochfrequen-

ter Prozesse unterbrochen werden.

4.4 Unterbrechungskonzept

Die optimale Ausnutzung und Auslastung aller Gerte eines Rechensystems legtMehrprogrammbetrieb nahe. Zerlegung der Ausfhrungsphasen eines Programmsin viele Einzelteile;

- Aufbrechen der Ausfhrung eines Prozesses in mehrere Phasen: u.a.Rechnen, E/A, Synchronisieren mit Partner.- Die Ausfhrung der Programme wird in der Regel mehrfach unterbrochen.

4.4.1 Motivation

Ursachen fr Unterbrechungen

zugeteilte Prozessorzeit ist aufgebraucht;bentigte Ressourcen stehen aktuell nicht zur Verfgung;ein E/A-Gert meldet sich zurck;ein Fehler tritt auf, z.B. Division durch 0;Systemaufruf (wurde bereits als spezielle Unterbrechung eingefhrt);

Bei einer Unterbrechung wird ein gerade aktiver Prozess unterbrochenund eine Unterbrechungsbehandlung durchgefhrt. Nach Beendigung derUnterbrechungsbehandlung kann prinzipiell ein beliebiger rechenbereiterProzess fortgesetzt werden.

Es ist erforderlich, bei der Unterbrechung den CPU Status des gerade aktivenProzesses fr die sptere Fortsetzung zu speichern.

Forderung: Eine Unterbrechung muss so kontrolliert erfolgen, dass eindefinierter Prozessstatus festgehalten werden kann.

4.4.2 Unterbrechungsarten

Die normale Programmausfhrung eines Prozessors kann auch durch mehrereArten von Unterbrechungen verndert werden. Man unterscheidet zwischensynchronen und asynchronen Unterbrechungen.

61


Unterbrechung

synchron asynchron

TrapAlarme

(Exception)Interrupt

Externe, asynchrone Unterbrechungen

Dies sind Unterbrechungen (Interrupts), die von auerhalb des zu unterbrechen-den Prozesses ausgelst werden, z.B. E/A-Kanal-"Endmeldung".

Der Ablauf im Rechnerkern (RK) wird unterbrochen und eine Unterbrechungs-anfangsbehandlung des Betriebsystemkerns wird aktiviert.

E/A-Kanal 2 CPU (RK) BS-Kern

Ende E/A

Auftrag

Unterbrechungs-

behandlung (UBH)

Interne, synchrone Unterbrechungen

Dies sind Unterbrechungen (Alarme, Exceptions), die durch den zu unterbrechen-den Prozess selbst ausgelst werden, z.B. Division durch 0.

62


Der Ablauf im RK wird unterbrochen und eine Unterbrechungsanfangsbehand-lung des Systemkerns wird aktiv.

CPU (RK) BS-Kern

Unterbrechungs-

behandlung (UBH)

Unterbrechung

arithmetischer Alarm

Beispiele von internen UnterbrechungenSpeicherschutzalarm: Prozess greift auf Speicherbereich zu, der nichtvorhanden ist oder auf den er nicht zugreifen darf.

Befehlsalarm: dem Operationscode des Maschinenbefehls ist keine Opera-tion zugeordnet.

Seitefehltalarm: Seite der virtuellen Adresse ist nicht im Arbeitsspeicher.

arithm. Alarm: arithm. Operation kann nicht ausgefhrt werden, z.B.Division durch 0.

Systemaufruf: kontrollierter bergang in das Betriebssystem.

4.4.3 Behandlung externer Unterbrechungen

Synchrone und asynchrone Unterbrechungen haben hardwaremig die Speiche-rung des aktuellen Prozessorzustandes zur Folge und lsen im Anschluss daraneinen indirekten Sprung ber eine im Speicher befindliche Sprungtabelle aus. Da-bei ordnet der Prozessor jeder synchronen und asynchronen Unterbrechung einenfesten Index in der Sprungtabelle zu. An dieser Stelle steht die Anfangsadresseder Unterbrechungsroutine, die entsprechende Folgemanahmen einleitet. Fallsmglich (Ausnahme ist z.B. ein arithmetischer Alarm) kann die unterbrocheneProgrammausfhrung durch die Wiederherstellung des gespeicherten Prozessor-zustandes zu einem beliebigen, spteren Zeitpunkt fortgesetzt werden.

63

mse course student

Documents