Kapitel 6: Betriebssysteme - Security Engineering Group | TU

Transcription

Grundlagen der Informatik III
WS 2009 / 2010
[Folien basierend auf VL von Prof. Eckert, WS 07/08,
und von Prof. Fellner WS 08/09]
Prof. Dr. rer. nat. Frederik Armknecht
Sascha Müller
Daniel Mäurer
Fachbereich Informatik / CASED
Mornewegstraße 30
64293 Darmstadt
Gliederung der Vorlesung GdI 3
1. Einführung
2. Assemblerprogrammierung
3. Leistungsbewertung
4. Speicherhierarchie
5. Assembler, Binder, Lader
6. Betriebssysteme und Ein-/Ausgabe
(Grundlagen)
7. Rechnernetze (Grundlagen)
8. Compiler (Grundlagen)
Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 2
Gliederung dieses Kapitels
6.1 Einführung
6.2 Betriebssystemstruktur
6.3 Varianten von Betriebssystemen
6.4 Interrupt und Systemaufruf
6.5 Prozess- und Prozessorverwaltung
6.6 Scheduling
6.7 Strategien zur virtuellen Speicherverwaltung
6.8 Dateien und Dateisystem
6.9 Ein-Ausgabe (I/O-Subsystem)
6.10 Busse (spezielle E/A-Geräte)
6.11 Synchronisation
6.1 Einführung
(Tanenbaum, Modern Operating Systems, 3e, Pearson)
6.1 Einführung
Einordnung eines Betriebssystems in ein Rechensystem
• Ein Rechnersystem besteht aus
• Hardware, System- und Anwendungsprogrammen
anwendungsunabhängige Systemprogramme (z.B. KommandoInterpreter (Shell), Compiler, Editoren,
Windows) im „user mode“
Betriebssystem (kernel/supervisor mode)
Befehlssatz-Architektur (ca. 50 bis 300
Instruktionen)
Zu Funktionseinheiten zusammengefasste,
physikalische Bauteile (z.B. CPU-Register, ALU)
Integrierte Schaltungen etc.
6.1 Einführung
Definition Betriebssystem (operating system)
(nach DIN 44300)
Die Programme eines digitalen Rechensystems, die zusammen mit den
Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten des
digitalen Rechensystems bilden, und die insbesondere die Abwicklung von
Programmen steuern und überwachen.

•
•
•
•
Aufgaben eines Betriebssystems
Abstraktion, bieten einer einfach zu nutzende Schnittstellen
Strategien zur Verwaltung gemeinsamer Ressourcen
nach festen Qualitätskriterien, Beispiele?
Dienste für Anwender und Anwendungsprogramme, Beispiele?
6.1 Einführung
BS-Aufgaben am Beispiel Windows 2000
6.1 Einführung
BS-Aufgaben am Beispiel Unix/Linux
Betriebssystemkern
6.1 Einführung
Bem.: Heutige Betriebssysteme sind historisch ‚gewachsen‘
Evolutionäre Weiterentwicklung, sehr komplexe Softwaresysteme
Komplexität von BS gemessen in Source Lines of Code (SLOC)
Werte unterschiedlicher Microsoft Windows Betriebssysteme:
Year
Operating System
SLOC (Million)
1995
Windows NT
4
1997
Windows 95
15
1998
Windows NT 4.0
16
1999
Windows 98
18
2001
Windows 2000
35
2002
Windows XP
40
2007
Windows Vista
50
Richtwert (Erfahrung): 5-50 Bugs pro 1000 Lines of Code!
Strukturiertes Design ist unabdingbar, sonst „a big mess“ (Tanenbaum)
6.2 Betriebssystemstruktur
Betriebssystem ist ein großes und komplexes System
• modularisiert in Komponenten und Subsysteme
• meist in C, C++ geschrieben (früher komplett in Assembler, heute nur noch
einige Gerätetreiber und Teile des BS-Kerns)
Kern („kernel“) umfasst die kritischen Funktionen des BS
Systemprogramme werden nach Bedarf geladen:
• z.B. Linker, Debugger, Kommandointerpreter (Shell), ...
Daemons: Hilfsprozesse
• erfüllen eine Service-Funktion,
• durch Ereignisse aufgeweckt
(„Datei zum Drucken eingetroffen“)
• Beispiele aus Unix:
6.2.1 Monolithische Systeme
Kapselung aller Betriebssystemdienste in einem große Kern
• idR Prozedur-orientiert, d.h. Systemdienste sind Prozeduren,
Aufruf des Dienstes (Systemcall) entspricht Prozeduraufruf
• z.B. UNIX/Linux: Module als Strukturierungshilfsmittel
Anwendung
Anwendung
Legende
System-Schnittstelle
BS-Kern
Prozess im
Benutzermodus
Systemprozedur
Systemaufruf
Nutzungsabhängigkeit
Hardware
Trennung zwischen Benutzerprogrammen und BS:
• Verschiedene Betriebsmodi:
• Benutzer- und Systemodus, dual-mode operation
• Schutz des BS vor fehlerhaften User-level Zugriffen!
• Modus wird in der Hardware durch 1 Bit festgehalten
• (1) System-Modus (engl. kernel mode, supervisor mode):
• Privilegierte Befehle sind verfügbar, u.a.
• Zugriff auf Hardware nur mit privilegierten Befehlen möglich
• Dienste des Betriebssystemkerns werden im Systemmodus
ausgeführt,
• beim Aufruf (system call): Moduswechsel
 Benutzer-Modus (engl. user mode): Benutzerprozesse
• In diesem Modus sind nur nicht privilegierte Befehle verfügbar,
z.B. Zugriff auf Prozessadressraum und unkritische Register
• Ausführung eines privilegierten Befehls führt zu einer
Unterbrechung (Interrupt)
• Aufruf eines Systemdienstes erfolgt über Systemcalls und
• führt zu einer Unterbrechung mit kontrolliertem Einsprung in das
BS
6.2.2 Virtuelle Maschine
• Unabhängigkeit und Isolation von Prozessen konsequent fortgeführt:
Illusion: jedem Prozess steht der gesamte Rechner allein zur
Verfügung
• unterschiedliche Betriebssysteme gleichzeitig auf einer vorhandenen
Hardware-Konfiguration
• z.B. VMware: Linux neben Windows
 Bem. Java Virtual Machine Konzept (JVM) rührt auch hier her
 Vorteil: vollständige Isolation der Benutzerprozesse (Schutz)
 Nachteil: schwierige gemeinsame Nutzung von Ressourcen, evtl.
Geschwindigkeit
6.2.2 Virtuelle Maschine
6.2.3 Client-Server Architektur mit Mikrokern
Zusammenfassung verwandter Systemdienste zu Diensteklassen
• Diensteklassen werden mit Servern (Serverprozessen) realisiert
• Clients (Clientprozesse) nutzen Dienste
• Kommunikation zwischen Client und Server ist notwendig:
klassisches Konzept hierfür: Nachrichtenaustausch
Mikrokern: Prinzip:
•Trennung von Strategie und Mechanismus
• Vorteil?
Mainframe-Betriebssysteme: Großrechner
• E/A-Kapazität ein wesentlicher Unterschied zum PC (z.B. tausende
von Festplatten und tausende von GB Daten-Kapazität)
• viele nebenläufige Prozesse mit viel Ein-/Ausgabe
Server-Betriebssysteme:
• Server-Rechner sind große PCs, Workstations oder Mainframes
• gleichzeitige Bedienung mehrerer Nutzer über ein Netzwerk zur
gemeinsamen Nutzung von Hard- und Software-Ressourcen, ServerFarmen sind heute Usus
• z.B. Datenbankserver, Web-Server
 Mehrprozessor-Betriebssysteme:
• Hochleistungsrechenkapazität durch Verbindung mehrerer CPUs zu einem
einzigen Rechnersystem, je nach Architektur: Parallelrechner,
Multiprozessoren, ...
• Aktuell: Entwicklung von Computer-GRIDs
• PC-Betriebssysteme: idR Ein-Benutzer-Systeme
• z.B. zu Textverarbeitung, Tabellenkalkulation, Internet-Zugriff
• Echtzeit-Betriebssysteme: Einhaltung von Deadlines etc.
• z.B. zur industriellen Prozess-Steuerung
• Eingebettete (embedded) Betriebssysteme:
• realisieren spezielle und keine allgemeinen Funktionen,
• müssen spezielle Größen-, Speicher- und Energie-Beschränkungen erfüllen
• z.B. Mobiltelefone, Smartcards
6.4.1 Interrupts (Unterbrechungen)
• Heutige BS arbeiten idR Ereignis (event) getrieben
• Auftreten eines Ereignisses wird durch Interrupt angezeigt:
• bei Hardware über Leitungen/Busse,
• bei Software: Systemaufruf
• Effekt: das laufende Programm wird unterbrochen und i.A.
später wieder fortgesetzt
Klassifikation der Unterbrechungsereignisse
• Interne Unterbrechung („trap“ oder „exception“): synchron
wird innerhalb der CPU selbst ausgelöst, z.B. Division durch 0
• Externe Unterbrechung: asynchron
wird ausgelöst durch Signal an Interrupt-Eingang der CPU, z.B. E/A
• Synchrone Interrupts sind reproduzierbar, asynchrone Interrupts
i.allg. nicht, Konsequenz:
• CPU muss stets auf Auftreten einer asynchronen Unterbrechung
gefasst sein, aber: eine Unterbrechung eines Programms ist nicht
immer gewünscht
• CPU kennt die Programmsemantik (z.B. Unterbrechung ok) nicht:
• deshalb: CPU bietet Konzept, um Unterbrechungen zu sperren
(disable), z.B. für kritische BS-Dienste nützlich
• Maskierbare Unterbrechung:
• Interrupt vorübergehend außer Kraft setzbar, z.B. E/A-Interrupt
• Das kann für gewisse zeitkritische Routinen z. B. in Gerätetreibern
notwendig sein
• Reaktion der CPU auf Unterbrechung: Start eines speziellen,
unterbrechungsabhängigen Programms („Interrupt Handler“)
Allgemeine Vorgehensweise zur Unterbrechungsbehandlung
normale Programmausführung
Interrupt
Behandlung der
Unterbrechung
Fortsetzung der normalen
Programmausführung
Rückkehr vom „Interrupt
Handler“
• Verzahnte Ausführung von „normalen“ Programmen und Unterbrechungsbehandlung: quasi-parallelen Ablauf: Synchronisation erf.
• Transparenzforderung: Unterbrechungsbehandlung hinterlässt
bzgl. des unterbrochenen Programms keine Spuren
Interrupt-Handling am Beispiel Tastatur
1. Bei Tastendruck wird ein entsprechender Interrupt ausgelöst.
2. Taste wird vom BIOS ausgelesen.
3. Entsprechender ASCII-Wert und Tastencode werden in einen Puffer
geschrieben.
4. Ein weiterer Interrupt wird ausgelöst, wenn die Taste losgelassen
wurde.
Aktionen des BS beim Auftreten eines Interrupts:
• CPU wechselt in Kernel-Modus
• BS-Kern sucht nach der Routine zur Behandlung des Interrupts:
• Suche im Interrupt-Vektor, der im BS-Kern verwaltet wird
• Interrupt-Handler von Geräten: Bestandteile der Treibersoftware
• Geräte-Nummer dient als Index in den Interrupt-Vektor
• der Interrupt-Vektor:
• enthält Anfangsadressen der Handlerroutinen,
• Tabelle ist idR resident in Bereich niedriger Adressen abgelegt,
• Tabelle: beim Booten mit den Routinen initialisiert
• Ausführung der Handler-Routine:
• Unterbrechungsgrund ermitteln, Behandlung durchführen
• Nach Beendigung: Return-from-Interrupt Befehl
Beispiel: Interrupt-Vektor Tabelle des Intel-Pentiums
6.4.2 Systemaufruf (engl. system call)
• Konzeptuell analog zu Interrupt, aber: Software-Unterbrechung
• System call: Schnittstelle zwischen Prozessen und BS
• meist als Assembler-Anweisung verfügbar bzw. nutzbar
• In der Regel aber nicht direkt, sondern über Routinen des
Laufzeitsystems der Programmiersprache nutzbar gemacht
• Laufzeitsystem (runtime system):
Menge von Bibliotheksfunktionen, vom Compiler automatisch
zum Programm hinzu gebunden
• z.B. Unix: Systemaufrufe direkt aus C, C++ Programmen,
Windows: Aufruf über Win32 API (Application Programmer
Interface)
Aufgabe: Transfer der Kontrolle an BS und Datentransfer,
z.B. read-Operation auf Dateien,
Parameter: Datei, Zeiger auf Buffer, Byteanzahl
Ablauf eines Syscalls:
Analogie zum klassischen Prozeduraufruf,
• Zu übergebene Parameter: über Stack, Register, Pointer
• Nummer des Systemaufrufs (Dienstnummer): idR in ein Register
geschrieben
• Kontrolltransfer an den BS-Kern über eine Trap-Instruktion
• Dienstnummer: Index in Dispatch-Tabelle (vgl. Interrupt-Vektor)
• Nach Beendigung des Dienstes:
• Kontroll- und Modus-Wechsel zurück zum Aufrufer des Syscalls,
• ggf. Blockieren des aufrufenden Prozesses, z.B. Prozess wartet
auf Eingabe
Beispiel: SysCall read (fd, buffer, nbytes) (Unix/Linux)
(5-6) Sys call read
durch Bibliotheksfunktion,
Trap-Befehl
(6)
Kern-Einsprung
mit ModusWechsel
(1-4) BenutzerProgramm:
Aufruf der
Bibliotheksfunktion read
mit Parameterübergabe
auf Stack etc.
(8-9) Ausführung des
read-Systemdienstes,
Return mit Modus-Wechsel
(7) Auswahl des Systemdienstes anhand der Dienstnummer im Register
Fachbereich
Dr. Frederik
Armknecht | 27Systeme (GRIS) | Prof. Dr. D. Fellner | 27
Fachbereich Informatik
Informatik || Prof.
Fachgebiet
Graphisch-Interaktive
Beispiel: Unix-Syscalls für Prozessmanagement
s ist Fehlercode,
pid ist Prozess ID
6.5 Prozess- und Prozessorverwaltung
Ziel: Konzepte, Datenstrukturen, Strategien zur Verwaltung
nebenläufiger Aktivitäten
Benötigt werden:
• Konzepte zur Virtualisierung der CPU
Lösung: Thread-, Prozess-Konzept
• Konzepte, um Informationen zu speichern
Lösung: Prozess-individueller Adressraum
• Datenstrukturen zur Verwaltung von Prozessen/Threads:
Lösung: Deskriptoren, Tabellen, Warteschlangen, etc.
• Operationen zur Verwaltung von Prozessen/Threads
Lösung: Scheduling, Prozess-Erzeugung etc.
6.5.1 Prozesskonzept
Ein Prozess ist eindeutig identifizierbarer Ablauf eines Programms,
d.h. ein Prozess ist ein Programm in Ausführung:
• jeder Prozess besitzt einen eigenen Adressraum,
• ein Prozess durchläuft unterschiedliche Zustände,
z.B. rechnend, wartend auf E/A , wartend auf CPU
Pseudoparallele Prozessausführung (Multiprogramming, multitasking):
• CPU wechselt zwischen der Ausführung verschiedener Programme
• Scheduling-Strategien erforderlich
(a) Multiprogrammierung
von 4
Programmen
(b) Konzeptmodell von 4 unabhängigen, sequentiellen Prozessen
Fachbereich
Dr. Frederik
Informatik || Prof.
Fachgebiet
(c) zu jedem Zeitpunkt
nur ein Programm aktiv
Dienste des Betriebssystems zur Prozessverwaltung:
• Prozess-Erzeugung und Starten (z.B. fork)
• Prozess-Terminierung, Auflösung (z.B. kill, exit)
• Strategien zur CPU-Zuteilung (scheduling)
• Prozessor-Anbindung (dispatching) (z.B. resume, sleep, wakeup)
Erzeugung von Prozessen: u.a.
• bei Systeminitialisierung,
• durch Benutzeranfrage
Terminierung von Prozessen: u.a.
• normaler Ausgang oder Fehlerausgang (freiwillig)
• Fataler Fehlerausgang (unfreiwillig)
• Abschuss durch einen anderen Prozess (unfreiwillig)
Beispiel: Zustandsübergangsdiagramm für Prozesse
Legende
Blau: Zustand
Schwarz: Übergang
9
Zombie
Prozess im Benutzermodus
1
Systemaufruf
return
return
2 im Kernelmodus
exit
sleep
unterbrochen
7
rechenbereit
im Speicher
wake up
4
wartend 3
genug Speicher
im Speicher
fork
swap out
swap in
8
swap out
erzeugt
5
6 zu wenig Speicher
wake up
wartend,
rechenbereit,
geswappt
geswappt
Fachbereich
Dr. Frederik
Informatik || Prof.
Fachgebiet
Prozesserzeugung
Alle Prozesse, die nicht zur Boot-Zeit erzeugt werden, entstehen, indem
ein laufender Prozess, z.B.
• laufender Benutzerprozess,
• von Tastatur oder Maus aufgerufener Systemprozess oder
• Batch-Manager-Prozess,
einen Prozesserzeugungsdienst aufruft.
Dieser teilt dem Betriebssystem direkt oder indirekt mit, welches Programm
im neuen Prozess auszuführen ist.
Erzeugung neuer Prozesse
• in Unix mit fork
• in Windows mit CreateProcess
Beispiel: Prozesserzeugung unter Unix: fork
• erzeugt exakten Klon des aufrufenden Prozesses.
• Kindprozess „erbt“ vom Vater-/Mutterprozess das Speicherabbild
(memory image – copy on write), die offenen Dateien, ….
• idR führt Kindprozess dann z.B. execve, um Speicherabbild zu ändern
und neues Programm auszuführen.
Beispiel:
• Benutzer tippt Kommando in Shell ein, z.B. sort,
• Shell erzeugt Kindprozess („forks off child process“),
• Kindprozess führt sort aus.
Dieser zweistufige Vorgang ermöglicht dem Kindprozess nach fork aber
vor execve die Manipulation seiner Datei-Deskriptoren, um Standard-Input
(stdin), Standard-Output (stdout) und Standard-Error (stderr) umzulenken.
Beispiel: Prozesserzeugung unter Windows
• Ein Win32 Funktionsaufruf, CreateProcess, behandelt beides:
Prozesserzeugung und Laden des korrekten Programms
• Aufruf hat 10 Parameter, u.a.
• das auszuführende Programm,
• die Kommandozeilenparameter zur Versorgung des Programms,
• verschiedene Sicherheitsattribute, …
• Win32 hat zusätzlich etwa 100 weitere Funktionen zur Verwaltung und
Synchronisation von Prozessen und verwandten Aufgaben.
• Nach der Prozesserzeugung haben in Unix und Windows
• Vater-/Mutter- und Kindprozess jeweils eigene Adressräume.
• Änderungen im eigenen Adressraum sind nicht sichtbar für den jeweils
anderen.
Prozesshierarchien: Entstehen durch Prozesserzeugung
 In Unix bilden Prozess mit allen Kind- und Kindeskindprozessen eine
Prozessgruppe (process group).
Z.B. wenn Benutzer Signal von Tastatur sendet, wird das zu allen
Mitgliedern der mit der Tastatur assoziierten Prozessgruppe übermittelt.
• Jeder Prozess kann Signal aufnehmen oder ignorieren.
 Initialisierung von Unix durch Starten des Prozesses init:
• Init liest beim Start eine Datei mit der Anzahl der Terminals und
• erzeugt (forks off) einen neuen Kindprozess pro Terminal.
• Diese warten auf einen Login-Vorgang.
• Bei erfolgreichem Login: Starten von Shells, GUI-Prozess, …
• Shells bearbeiten Kommandos, z.B. zur Prozesserzeugung
• Alle Prozesse zu einem einzigen Baum mit init als Wurzel.
6.5.1 Einfaches Multiprogramming Modell
 Oft wichtiges Ziel von Multiprogramming:
Maximierung der CPU Auslastung
 Beobachtung: Prozesse blockieren oft aufgrund von I/O Operationen
 Frage: Welches Multiprogramming Level (=Anzahl an parallelen
Prozessen) wird benötigt, um bei gegebener Blockierungswahrscheinlichkeit der Prozesse eine bestimmte CPU Auslastung zu
erzielen?
 Einfaches Modell:
 p: Wahrscheinlichkeit, dass ein gegebener Prozess blockiert
 n: Anzahl Prozesse
 pn: Wahrscheinlichkeit, dass alle Prozesse gleichzeitig blockieren
 (1 - pn): durchschnittliche CPU Auslastung
6.5.1 Einfaches Multiprogramming Modell
Aussage des Modells? Beschränkungen?
Degree of multiprogramming
6.5.2 Datenstrukturen zur Prozessverwaltung
Prozesskontrollblock (Prozessdeskriptor): PCB
• Beschreibt den Kontext eines Prozesses; enthält i.d.R. folgende
Informationen:
• eindeutiger Name, z.B. fortlaufende Nummerierung des
Prozesses (z.B. pid in UNIX)
• Name des Benutzers, dem der Prozess zugeordnet ist, Namen
der zugeordneten Gruppen
• Prozesszustand (wartend, rechnend, rechenwillig, ...)
• Spezifikation des Ereignisses, auf das der Prozess wartet (z.B.
warten auf Eingabe von Tastatur (E/A-Auftrag))
• Scheduling Informationen: z.B. Ablaufpriorität, bereits verbrauchte
CPU-Zeit
PCB-Bestandteile: Forts.
• Registerinhalte, wie Programm-Zähler (PC), Stackpointer, etc.
• Accounting-Information: verbrauchte Ressourcen etc.
• Prozesshierarchie: Vaterprozess, Kind-Prozesse
• Informationen für das Speichermanagement
• Informationen für die Dateiverwaltung: u. a. Home-Verzeichnis
• Liste der zugeordneten E/A-Geräte
PCB-Information
Prozess-Image im Speicher
• der PCB eines Prozesses
gehört zum Prozessadressraum
• zur Prozessverwaltung müssen
Teile des PCB in dem
Hauptspeicher eingelagert sein
• ein Verweis auf den PCB eines
Prozesses wird in der
systemglobalen Prozesstabelle
des BS verwaltet
PCB i
PCB j
Stack-Bereich i
Stack-Bereich j
Privater ProzessBereich:
Code, Daten
Privater ProzessBereich:
Code, Daten
Shared Bereich
Shared Bereich
Prozess i
Prozess j
Prozesstabelle:
• enthält Verweise auf die PCBs existierender Prozesse
• idR als Tabelle fester Länge organisiert, d.h. die maximale Prozessanzahl
ist durch Systemparameter festgelegt
• Suchen nach PCB-Verweisen: anhand der Prozess-ID (pid)
• Suchalgorithmen: Hashing, Suchbäume etc.
pid=2
PCB0
PID
PCB1
Zustand
Registerinhalte
PCB2
Prozess-Tabelle
Schedulinginfo
...
Prozess-Warteschlangen:
Zur Prozess-Verwaltung führt das BS unterschiedliche Warteschlangen.
Die wichtigsten sind:
• Ready-Queue(s) für rechenbereite Prozesse
• Warteschlangen für verschiedene Ereignisse
•blockierte Prozesse
•i.d.R. jeweils eine eigene Warteschlange für E/A-Geräte
(z.B. Platte, Terminal)
•Verwaltung der Prozesse z.B. durch verkettete Listen der PCBs
• oder wie beispielsweise in Linux (ab 2.6): Rot-Schwarz-Bäume, die
nach Zeit geordnet sind
6.5.3 Thread-Konzept (lightweight Process)
Bislang betrachtet:
• Sequentieller Prozess mit virtuellem Adressraum und
• einem Kontrollfluss (Thread of control)
• Multi-threaded Prozess:
• Prozess mit mehreren, parallelen Kontrollflüssen, d.h.
• multi-threaded Prozess kann parallele Aktivitäten ausführen
Charakteristika: ein Thread besitzt:
• eine eigene Identität: Thread-ID,
• einen eigenen Programmzähler,
• einen eigenen Stack, eigenes Registerset und
• einen eigenen Zustand (blockiert, rechenbereit, rechnend etc.)
6.5.3 Thread-Konzept
Threads des gleichen Prozesses: teilen sich den gemeinsamen
Prozessadressraum, nutzen gemeinsame Ressourcen
Konsequenz: jeder Thread kann auf jede Speicheradresse zugreifen,
z.B. auch auf den Stack anderer Threads des Prozesses
Adressraum
Thread
...
Single-threaded Prozess
Adressraum
Thread
...
Thread
...
Thread
...
Multi-threaded Prozess
• Multi-threading: effiziente Kooperation zwischen Threads möglich
• Threads greifen auf globale Variablen des Prozesses gemeinsam zu:
Synchronisationskonzepte erforderlich!
Informationen pro Prozess
Thread-Beschreibung:
durch
Thread Control Block
Informationen
pro Thread
Programzähler
Stack
Register-Set
Kind-Threads
Zustand
Programzähler
Adressraum
Stack
globale
Variablen
Register-Set
geöffnete
Dateien
Kind-Threads
Kind-Prozesse
Zustand
Timer
Signale
Semaphore
Accounting Informationen
Zustand
Vorteile des Thread-Konzepts
• Pro Prozess viele parallele Aktivitäten, aber einige sind von Zeit zu
Zeit blockiert.
• Durch Zerlegung des Prozesses in quasi-parallel ausführbare
Ausführungsstränge: vereinfachtes Programmiermodell
• Gemeinsame Nutzung von Daten: sehr schneller Datenaustausch,
kein Versenden von Nachrichten notwendig
• Threads sind schneller zu erzeugen und zu terminieren als Prozesse
(z.B. um Faktor 100).
• Performanz-Steigerung durch Threads:
• Z.B. umfangreiche Berechnungen und umfangreiche Ein-/Ausgabe
kann überlappend abgearbeitet werden.
• Echte Parallelität auf Mehrprozessor-Rechnern
(am Beispiel einer Textverarbeitungssoftware)
 Beispiel: Text-Verarbeitungsprogramm mit 3 Threads
Interaktiver Thread:
wartet auf Eingaben
von Tastatur und Maus
Thread zur
Reformatierung
(Neuberechnung) des
Textes im Hintergrund
nach Eingaben und
zur Darstellung auf
Bildschirm
Thread zum Anlegen
von Sicherungskopien
im Hintergrund
(am Beispiel eines Webservers)
•
•
•
•
Dispatcher-Thread: Annahme von Anfragen aus dem Netz
Weiterleitung an einen Worker-Thread
Worker prüft, ob Anfrage aus Cache erfüllbar, falls nicht:
Lese-Anfrage an Platte, Worker wird blockiert, bis Antwort vorliegt
worker
Cache von
Web-Seiten
BS-Kern
Netzverbindung
while(TRUE){
getNextRequest(&buf);
handoffWork(&buf);
}
while(TRUE){
waitForWork(&buf);
lookForPagInCache(&buf,&page);
if(pageNotInCache(&page)){
readPageFromDisk(&buf,&page);
}
returnPage(&page)
}
Dispatcher
Worker
Kernel
Space
Kern
User-level Threads
Fachbereich
Dr. Frederik
Informatik || Prof.
Fachgebiet
Thread3
Thread2
Thread1
User Space
Laufzeitsystem
Thread-Verwaltung
Kernel
Space
Thread3
Thread2
Thread1
User Space
Thread Implementierung
Ansätze:
• in User Space über Thread-Pakete, Bibliotheken
• Kern-integriert: d.h. BS-Kern bietet Thread-Konzept
• Kombination
Kern
Thread-Verwaltung
Kernel-level Threads
User-level Threads:
• Kern besitzt keine Kenntnis über Threads
• Kern verwaltet nur Prozesse (Scheduling, Signale etc.)
• Realisierung der Operationen zur Threadverwaltung mit
Thread-Paket, z.B. für Unix-Systeme pthreads Bibliothek
• Thread-Paket setzt auf beliebigem BS auf,
keine BS-Änderung nötig
• Paket stellt als Laufzeitsystem eine Menge von
Operationen zur Verfügung: create, wait, etc.
• für jeden Prozess wird vom Laufzeitsystem (nicht vom BS-Kern!)
eine Threadtabelle verwaltet
• das Laufzeitsystem bietet Schedulingoperationen für Threads
eines Prozesses, d.h. two-level Scheduling, Vorteil? Nachteil?
Probleme bei user-level Implementierungen: u.a.
• Implementierung von blockierenden Systemaufrufen:
• alle User-level Threads des Prozesses werden blockiert, keine
Parallelverarbeitung mehr
• Ähnlich: Blockierung aufgrund Page Fault eines Threads
• Scheduling des Kerns greift nicht (z.B. keine Uhrunterbrechung),
• u.U. kann ein Thread alle anderen monopolisieren,
• d.h. Threads müssen CPU freiwillig abgeben
Fazit:
Herausziehen von BS-Diensten aus dem Kern in den User-Level:
• Flexibilität: individuelle Anpassung an Anforderungen der
Anwendung (z.B. individuelles Scheduling ihrer Threads)
• keine globale Strategie (Fairness etc.)
Kernel Level Implementierung
• Kern verwaltet Threads selber:
• eine Thread-Tabelle für alle Prozesse im Kern
• Thread-Operationen wie –Erzeugung, -Terminierung etc. sind
Kern-Aufrufe: trap in den Kern
• blockierender Aufruf: welche Scheduling-Optionen?
• Effizientes ‚Recycling‘ von Thread Datenstrukturen
Beispiele:
•Linux: Kernel-level Threads
•Windows2000: Kernel-level und User-level Threads
Hybride Lösung: Kernel + User Threads
6.5.4. Kontextwechsel
Aufgabe des Dispatchers: Prozess an CPU binden
• Analog zur Unterbrechung einer CPU, aber größerer Kontext
Bei einem Kontextwechsel ist durchzuführen:
• Retten der Prozessumgebung des aktuellen Prozesses, inkl. PC,
Registerinhalte
• Update des PCB des aktuellen Prozesses um neue Zustandsinformation,
eintragen in Verwaltungsdatenstrukturen (dann: Auswahl eines Prozesses)
• Update des PCB des neuen Prozesses, Update der Datenstrukturen für
Speichermanagement
• Laden des Prozess-Kontexes
Bem.: Kontextwechsel sind teuer (ca. einige 1000 Instruktionen),
Anzahl der „Prozesswechsel“ pro Sekunde sollte klein sein:
• Strategie ist erforderlich: Scheduling
6.6 Scheduling
Im Alltag: Planen, Organisieren von Abläufen und Ereignissen
• z.B. Stundenplan, Fahrpläne, OP-Einsatzplan, etc.
CPU – Scheduling:
• Strategische Entscheidung treffen: welchen Prozess, wann, wie lange an CPU
zu binden
• Ausnutzen: CPU-Nutzungsbursts wechseln sich mit E/A-Wartephasen ab
6.6.1 Kriterien beim Scheduling
Wann sind Scheduling-Entscheidungen zu treffen?
• Prozesserzeugung (z.B. fork)
• Prozess (wird) terminiert
• Prozess blockiert (z.B. I/O, Semaphor)
• I/O Interrupt
• Clock Interrupt (bei präemptiven Scheduling)
Kriterien:
• Effizienz: CPU (bzw. allg.: Ressourcen) so gut wie möglich auslasten
• Durchsatz: max. Anzahl ausgeführter „Jobs“ pro Zeiteinheit
• „Turnaround“: min. Verweilzeit für einen einzelnen Prozess
• Antwortzeiten interaktiver Prozesse minimieren
• Fairness
Gewichtung der Scheduling-Ziele kann variieren
Batch Systeme
 Durchsatz, Turnaround, CPU Auslastung
Interaktive Systeme
 Antwortzeit, Proportionalität
Echtzeitsysteme
 Vorhersagbarkeit, definierte Anforderungen einhalten
Allgemein
 Fairness
 Einhaltung von Regeln
 Balancierung
 Schwierigkeiten:
 Optimierungskriterien beim Scheduling teilweise widersprüchlich
 Optimieren nach Mittelwert oder Extremwert oder Varianz?
 Prozessverhalten („kommt der nächste E/A-Befehl bald?“)
kann vom Scheduler nur vermutet, aber nicht exakt vorhergesehen werden.
 Frage: wie soll man Hypothesen über Verhalten erstellen?
Kenngrößen zur Bewertung von Scheduling-Verfahren: u.a.
• mittlere Wartezeit, mittlere Verweilzeit, CPU Auslastung
Gegeben ist eine Strategie S und
• die Ankunftszeiten (Erzeugungszeitpunkte)
a = (a1, ..., an ) der Prozesse Pi,
• und die Bedienzeiten (benötigte Prozessorzeit)
b = (b1, ..., bn ) der Prozesse
• Abgangszeit ci (a,b,S) von Pi
• Verweilzeit vi (a,b,S) = ci (a,b,S) - ai von Pi
• Wartezeit wi (a,b,S) = ci (a,b,S) - ai – bi von Pi
• Mittlere Verweilzeit V(a,b,S) = 1/n Σi=1 vi (a,b,S)
• Mittlere Wartezeit W(a,b,S) = 1/n Σi=1 wi (a,b,S)
6.6.2 Strategie – Klassen
(1) Nicht unterbrechend (non preemptive, run to completion):
• Scheduling nur dann möglich, wenn der rechnende Prozess
blockiert wird oder wenn er terminiert
• einfach zu implementieren, aber Gefahr des Monopolisierens
• Beispiele:
• FCFS (first come first served)
• Shortest Jobs First
• Nicht unterbrechende Strategie: z.B. in Microsoft Windows 3.x
(2) Unterbrechende Strategie (preemptive):
• Unterbrechung beim Eintreten von speziellen Ereignissen,
z.B. I/O Interrupt, Clock Interrupt, Blockierung
• Beispiel: Zeitscheiben-Strategie (Round-Robin), Prioritäten
• Präemptive Strategien u.a. in Windows2000, Vista, Unix-Derivate
6.6.3 Mehr-Schichten Scheduling
Idee: analog zur Speicherhierarchie:
• Anbindung an CPU muss sehr schnell gehen,
• Prozesse müssen vorbereitet sein: eingelagert im Speicher,...
Lösung: Scheduling auf unterschiedlichen Stufen:
• long-, medium-, short-term (CPU-Schedling)
Long-term Scheduling (LTS): nicht immer vorhanden
• Auswahl rechenwilliger neuer Aufträge, meist Jobs aus dem
Hintergrundbetrieb (batch) und Einlagerung in den Hauptspeicher
• Einfügen der Prozesse in die Ready-Queue
• LTS wird relativ selten aufgerufen, u.U. erst nach Minuten
Medium-term Scheduling:
• bei Überlast werden Prozesse auf Hintergrundspeicher
ausgelagert (swap out) und später eingelagert (swap in)
• kann notwendig sein, um Prozessmix zu verbessern,
was ist ein Prozessmix? Was ist guter Mix?
Short-term Scheduling: (CPU-Scheduling)
• Auswahl eines geeigneten Prozesses aus der Ready-Queue
• Warteschlange häufig als FIFO (First in – first out) Warteschlange
realisiert
• häufig aufgerufen: mind. einmal alle 10 – 100 Millisekunden
• CPU-Scheduler ist zeitkritisch: Beispiel:
• Scheduler benötige 1 ms für Auswahlentscheidung,
• Prozess erhält 10 ms Rechenzeit, dann verschlingt
Scheduling allein 1/11 = 9 Prozent der CPU-Zeit!
6.6.4 Zeitscheibenstrategie (Round Robin)
In heutigen Standardbetriebssystemen:
Kombination aus Zeitscheiben- und Prioritätsbasierten Strategien
• Prozesse erhalten CPU jeweils für eine festgelegte Zeitdauer
(Zeitscheibe) d
• spätestens nach dem Ablauf
Warteraum
von d: CPU wird entzogen
Prozessor
• zyklisches Bedienen
der Prozesse
Ankunft von
• Ready Queue als
zyklische Schlange
Prozessen
realisiert
nicht beendete
Aufträge
Terminierte
Prozesse
6.6.4 Zeitscheibenstrategie (Round Robin)
Gegeben seien n Prozesse in Warteraum und eine Dauer d
• jeder Prozess muss max (n – 1) * d Zeiteinheiten warten,
bis er wieder an der Reihe ist
• Probleme: Wahl der Dauerlänge
• Dauer zu groß: Effekte?
• Dauer sehr klein, dann process sharing, Probleme?
• Daumenregel: 80 Prozent der benötigten CPU-Zeit sollte
kleiner als d sein.
• Typische Werte für d: 10 bis 100 ms (z.B. 4.3 BSD Unix 10ms)
• Bem.:
Für d = 100ms bei 1MIPS Maschine:
ca. 100.000 Instruktionen pro Zeitdauer d
6.6.4 Zeitscheibenstrategien: Übersicht
τ
d=1
d=4
τ
Quelle:
W. Stallings
Operating Systems
(Prentice Hall)
6.6.5 Prioritäten - Strategie
Hintergrund
• bei Zeitscheibe implizit: alle Prozesse sind gleich wichtig,
• das ist nicht immer gewünscht (z.B. Systemprozesse)
• Lösung: Prozesse erhalten Priorität
Statische Prioritätenvergabe:
• jeder Prozess besitzt für die Dauer seiner Existenz eine
feste Priorität
• Problem: Gefahr des Verhungerns (starvation) von
Prozessen mit niedriger Prio
• Gerücht: bei Abschaltung der IBM 7094 am MIT 1973:
Entdeckung eines nicht bearbeiteten, niedrig
prioren Prozesses von 1967
Dynamische Prioritätenvergabe:
• die Prioritäten der Prozesse werden in gewissen
Zeitabständen neu berechnet.
Kombination: mehrschichtige Warteschlangen (multi-level queues)
• in heutigen BS häufig: Multi-level Feedback Queues, d.h.
• Prozesse werden gemäß ihrer Priorität in Schlange eingeordnet
• Dynamik: Prozesse können zwischen Schlangen wandern.
• Notwendig:
• Schedulingverfahren pro Schlange: meist RR
• Scheduling zwischen Schlangen: meist nach Prioritäten
• Verfahren zur Neuberechnung der Prioritäten mit ggf.
Wechsel der Warteschlange
Beispiel: sowohl Unix-Familie als auch Windows-Familien
verwenden Varianten von Multi-level Feedback Queues
Beispiel: Scheduling im BSD-Unix Betriebssystem
• 32-schichtiges Warteschlangen Scheduling
• Zeitscheibenstrategie (RR) mit überlagerter dynamischer
Prioritätenvergabe
• Dauer d = 100ms
• Prioritäten von 0 – 127 (0 ist die höchste)
• Prozess mit Priorität PRIO: in Schlange PRIO/4 eingeordnet
• Jede Warteschlange wird mit Zeitscheibenverfahren bedient
• Fortlaufende Neuberechnung der Prioritäten
Neuberechnung der Prioritäten:
• p_cpu: geschätzte CPU-Nutzung des aktiven Prozesses
• alle 10 ms (Uhrunterbrechung, Tick): p_cpu : = p_cpu + 1
• p_nice vom Benutzer bestimmter Gewichtungsfaktor (-20 ≤ p_nice ≤ 20)
• positiver Wert bedeutet, dass Prozess bereit ist, weniger als den ihm
zustehenden Anteil an Prozessorzeit zu beanspruchen
• USER_PRIO Priorität, die dem Prozess beim Start zugeteilt worden ist.
• nach 4 Uhrunterbrechungen (Ticks) Neu-Berechnung der Prios aller
rechenbereiten Prozesse
p_cpu
u_prio = USER_PRIO +
4
+ 2 p_nice
• damit Prios nicht ständig wachsen, wird p_cpu jede Sekunde angepasst
durch
2load
p_cpu =
* p_cpu + p_nice
2load+1
• Bem.: load ist eine Abschätzung der CPU-Auslastung
Durchschnitt der rechenbereiten Prozesse über vorangegangenes
1-Minutenintervall
• Problem:
 Prio-Neuberechnung nur für rechenbereite Prozesse
 Passiv wartende Prozesse profitieren davon nicht
• notwendig: Prio-Neuberechnung wartender Prozesse:
 Basis: Variable p_slptime , enthält Schätzung der Wartezeit des
Prozesses in Sekunden
 Beim Aufwecken des Prozesses:
2load p _ slptime
)
* p _ cpu
p _ cpu = (
2load + 1
6.6.6 Weitere Verfahren
 Guaranteed Scheduling
 Jeder User (jeder Prozess) soll annähernd gleich viel CPU erhalten
 System beobachtet tatsächlichen CPU Verbrauch + steuert entsprechend
 Lottery Scheduling
 Prozesse halten Lose zur Teilnahme an Ressourcen-’Verlosung’
 System führt regelmäßig Lotterie aus
 Div. Ansätze möglich:
 Zuweisung von Losen zu neuen Prozessen
 Tausch von Losen zwischen Prozessen
 Einfach zu implementieren, transparent
 Fair Share Scheduling
 Verteilung von Ressourcen berücksichtigt Prozess-Eigentümer
 Aufteilung so, dass alle Eigentümer gleich (oder entspr. einem Verhältnis)
bedient werden
Erinnerung
• Virtuelle Adressräume in Seiten (pages) aufgeteilt
• Hauptspeicher ist in Seitenrahmen (frames) aufgeteilt
• Einlagern von Seiten in die Frames
• Seitentabelle(n) und Adressabbildung (vgl. Kapitel 4)
Jetzt
klären wichtiger strategischer Aufgaben
• Ladestrategie: welche Seite(n) ist/sind zu laden?
• Platzierungsstrategie: welcher Frame ist geeignet?
• Seitenersetzung: welche Seite(n) auslagern?
(Wdh. aus Kapitel 4)
Virtual addresses
Vergleich mit Caches
• Blöcke  Seiten (pages)
• Cache-miss  Seitenfehler
(page fault)
• Adressen im Programm:
virtuelle Adressen
• Adressen im Hauptspeicher:
(reale) physikalische Adressen
• Dynamische Zuordnung von
Programmadressen zu
Hauptspeicheradressen durch
Adressabbildung
Physical addresses
Address translation
Disk addresses
Programm wird in unterschiedliche
Bereiche des Hauptspeichers
geladen: „Relocation“
6.7.1 Ladestrategie
Einzelseitenanforderungs-Strategie (demand paging):
Idee: eine Seite wird genau dann geladen, wenn auf sie zugegriffen wird
und sie noch nicht eingelagert ist
• Hardware-Unterstützung dafür: Valid-Bit für jede Seite
• Demand Paging ist häufigste Strategie in heutigen BS;
Seiten-Pre-Fetching:
Idee: Seiten werden im Voraus geladen, um sie sofort bei Bedarf
verfügbar zu haben
6.7.1 Ladestrategie
Demand-Paging: Leistungsanalyse
Page Fault Rate 0 <= p <= 1
• if p= 0, keine Page Faults.
• if p= 1, jede Referenz (Zugriff) führt zu einem Page Fault
Fehlerbehandlung kostet Zeit: wesentliche Beiträge dazu
• Behandlung des Interrupts (~ 1 – 100 µs)
• Einlagern der Seite (~ 24 Millisekunden: typische Latenzzeit der
Platte: 8ms, Suche 15ms, Datentransfer 1ms)
• Re-Start des Prozesses (~ 1 – 100 µs)
• Memory access time = ~ 10 – 200 Nanosekunden
Effective Access Time (EAT):
EAT = (1 – p) * memory_access_time + p * (page_fault_overhead
+ [swap_page_out] + swap_page_in + restart)
6.7.1 Ladestrategie
Annahme:
• durchschnittliche Zeit zur Seitenfehler-Behandlung :
sei 25 Millisekunden ( = 25.000 µs = 25.000.000 Nanosek)
• Speicherzugriffszeit liege bei 100 Nanosekunden
• dann gilt für EAT (in Nanosekunden):
EAT = (1 – p) * 100 + p (25 Millisekunden)
= (1 – p) * 100 + p * 25.000.000
= 100 + 24.999.900 * p
D.h. EAT ist direkt proportional von Fehler-Rate p abhängig
• Falls z.B. alle 1000 Zugriffe 1 Fault: EAT = 25 µs
• d.h. Verlangsamung um Faktor 250 durch Demand Paging
6.7.1 Ladestrategie
Um eine Verlangsamung um weniger als 10% zu erhalten:
• notwendig:
110 > 100 + 25.000.000 * p
10 > 25.000.000 * p
p < 0,0000004
• d.h. um Page-Fault Rate auf akzeptabler Größe zu halten, darf
höchstens ein Page-Fault auf 2.500.000 Zugriffe auftreten!
Fazit:
• gute Seitenersetzungstechniken sind erforderlich
• zusätzliche Maßnahmen zur Reduktion der Zugriffszeiten:
u.a. Nutzung von TLB
6.7.2 Seitenersetzungsstrategien
FIFO
Verdrängen der ältesten Seite, d.h. Kriterium ist die Zeit, wann die Seite
eingelagert wurde
Beispiel:
Vorteil von FIFO: einfach zu implementieren
 z.B. über FIFO-Queue, Zeitstempel sind nicht erforderlich
 aber wirklich gute Strategie?
• Schlechtes Leistungsverhalten, warum?
Beispiele für ungünstige Szenarien (Charakteristika)?
• FIFO-Anomalie können auftreten: trotz Erhöhen der Anzahl der
Frames steigt die Seiten-Fehler Zahl!
Beispiel für Anomalie:
 Gegeben sei der Referenzstring: 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5
3 Frames
4 Frames
1
1
4
5
1
1
5
4
2
2
1
3
2
2
1
5
3
3
2
4
3
3
2
4
4
3
9 page faults
Frage: Abänderung? Effizient und effektiv?
10 page faults
Second Chance: FIFO-Variante
• Zugriffbits „r“ einer Seite wird gesetzt, wenn darauf zugegriffen wird.
• Überprüfen des Zugriffsbits der ältesten Seite.
• falls r=0, dann ist die Seite alt und nicht benutzt,
• falls r=1, Seite an das Ende der Seitenliste anhängen
• r-Bit wird gelöscht, Ladezeit der Seite wird aktualisiert
Lade-Zeit der jeweiligen Seite
Page-Fault zum Zeitpunkt 20,
R-Bit von Seite A sei gesetzt
Fachbereich
Dr. Frederik
Informatik || Prof.
Fachgebiet
A wird mit
neuem
Ladezeitpunkt
20 umgehängt
Clock Algorithmus
•
effiziente Implementierung des Second Chance Algorithm.
•
Ansatz: Seiten werden in zyklischer Liste verwaltet (Uhr)
•
Der Zeiger der Uhr zeigt auf die älteste Seite.
•
Seitenfehler: Seite unter der Zeigerposition:
• falls r=0, auslagern der Seite, und Zeiger vorrücken.
• Anderenfalls r:=0 und Zeiger vorrücken bis Seite mit r-Bit = 0 gefunden
Worst Case:
• alle r-Bits gesetzt
• alle Seiten erhalten 2-te
Chance
• degeneriert zu FIFO!
Fachbereich Informatik | Fachgebiet Graphisch-Interaktive Systeme (GRIS) | Prof. Dr. D. Fellner | 85
LRU (Least recently used)
• Verdrängen der am längsten nicht genutzten Seite,
• im Vergleich zur optimalen Strategie: Blick in die Vergangenheit und nicht in
die Zukunft
Beispiel: 12 Faults (anstelle von 15 Faults bei FIFO)
LRU ist gute Strategie, aber sehr aufwändig exakt zu implementieren, wird
meist nur approximiert
Aging-Verfahren: Approximation von LRU
• Idee: Unterscheidung zwischen aktuellen und lange zurückliegenden
Zugriffen ermöglichen
• r-Bit allein ist dafür aber zu undifferenziert, deshalb wird mit jeder
Seite ein Counter verbunden, meist 8-Bit Counter, initialisiert mit 0
Bei jedem Timerinterrupt: für jede Seite:
• Counter wird um 1 Bit nach rechts geshiftet
• Wert des r-Bits wird zu Counter auf das am weitesten links
stehenden Bit hinzuaddiert
Beim Seitenfehler wird Seite mit kleinstem Counter-Wert zur Ersetzung
ausgewählt
Beispiel: Software-Approximation von LRU mit
• 8 Bit Counter pro Seite und
• r-Bit gesetzt durch Hardware sowie Timerinterrupts
Unterschied zu exaktem LRU? 8-Bit Counter ausreichend?
Beispiel Seitenersetzung unter 4BSD-Unix
• Kombination aus Paging und Swapping
• Paging: teilweise durch BS-Kern und teilweise durch
Systemprozess: Pager-Daemon (Prozessnummer 2)
• Pager-Daemon wird periodisch alle 250 msec gestartet
• Pager-Daemon führt Seitenersetzungen durch:
• falls Anzahl der freien Frames < lotsfree,
• Zurückschreiben von Seiten auf Platte (=> immer mind.
lotsfree freie Frames)
• Bem.: lotsfree i.d.R. ¼ des Arbeitsspeichers
• Globale Seiten-Ersetzungstrategie:
• 2-Hand Clock-Algorithmus auf der Core-Map (=Tabelle mit
einem Eintrag per Frame)
Aufteilung des Arbeitsspeichers
(1) nicht auslagerbarer BS-Kern, (2) Frames, (3) Core Map:
nicht auslagerbare Frame-Tabelle: pro Frame ein Eintrag
2-Hand Clock-Algorithmus: 2 Zeiger in Core Map
• Überprüfen der Seite unter vorderem Zeiger:
Zurücksetzen des Zugriffbits (r),
• Überprüfen der Seite unter hinterem Zeiger:
Auslagern, falls r=0
• Nach Prüfung: beide Zeiger vorrücken, bis genügend freie Seiten
(lotsfree)
• Swapper-Prozess:
wird gestartet, falls Paging-Rate zu hoch wird und die Anzahl der freien Frames
ständig < lotsfree
• Swapper (PID 0) prüft, ob ein Prozess > 20s untätig war;
der am Längsten untätige Prozess wird ausgelagert
• Auslagerung wird für weitere Prozesse solange wiederholt, bis genügend freier
Speicher verfügbar
• falls keine lange wartenden Prozess gefunden:
• prüfe die vier größten Prozesse
• Auslagern des am längsten untätigen Prozesses
• Swapper prüft regelmässig (nach wenigen Sekunden), ob rechenbereite
Prozesse einzulagern sind
• Auswahlfunktion: gewichtet nach Länge der der Auslagerungszeit, Größe des
Prozesse, Wartezeit etc.
• Swap-in großer Prozesse nur, wenn genügend Speicher vorhanden, da Einlagern
aufwändige Operation
6.8 Dateien und Dateisystem
6.8.1 Datei-Konzept
Motivation:
• Vielzahl unterschiedlicher Speichermedien: Bänder, Platte etc.
• Abstraktion von physikalischen Speicher-Eigenschaften: Definition
einer logischen Speichereinheit (Datei)
• Notwendigkeit zur langlebigen Datenspeicherung! D.h. Speicherung im
Prozessadressraum ist nicht sinnvoll! Warum?
Lösungsansatz: Datei
• Konzept zur dauerhaften (persistenten) Speicherung
von Daten, Informationen, Programmen auf
• Platten oder anderen externen Speichermedien
6.8.1 Dateikonzept
Persistente Speicherung: Dateien überdauern das Terminieren
von Prozessen, durch die sie erzeugt wurden
Datei:
Information gespeichert als:
• Folge von Bytes (z.B. Unix)
• oder als Folge von Records
• Benutzer legt Semantik fest
• BS kennt keine Semantik, es verwaltet nur
uninforme, benannte Container
Dateiattribute: Information über Datei: u.a.
• Name, Daten, Erzeugungszeitpunkt, Schutzbits,
• Größe, Zeitpunkt der letzten Änderung,
• Zeitpunkt des letzten Zugriffs, ...
6.8.1 Dateikonzept
Beispiele für Datei-Attribute
6.8.1 Dateikonzept
Dateitypen: Klassen von Dateien mit Charakteristika:
• üblicherweise ist die Typ-Identifikation Teil des Dateinamens, das ist die sog.
Datei-Extension
Beispiele: vgl. Tabelle
Sinn der Extension:
• Hinweise für BS über den Typ
der gespeicherten Daten
• z.B. BS kann beim Öffnen
einer .doc Datei die
assoziierte Anwendung
starten, z.B. Word-Prozessor
prn, ps, pdf
mpeg, mov, rm
6.8.1 Dateikonzept
Beispiele: Datei-Typen unter Unix
(a) ausführbare Datei, Magic Number enthält Infos über Typ
(b) Archiv-Datei
weitere Typen u.a.
• gewöhnliche Dateien:
ASCII oder Binärdatei
• Verzeichnisse
• Zeichenorientierte
Spezialdatei: serielles
E/A-Geräte
• ...
6.8.1 Dateikonzept
Datei-Strukturierung
• meist hierarchische Struktur (Bäume, Graphen)
Verzeichnis-Datei: Zusammenfassung von Dateien
• Verzeichnis (directory) enthält Verwaltungsinformationen
Aufteilung der Plattenspeicher in Partitionen (Volumes)
• Device-Directory (Volume Table) enthält Informationen
über die Dateien (Verzeichnisse) in der Partition
Typische
DateisystemOrganisation
6.8.1 Dateikonzept
zwei-stufiges Verzeichnis
Hierarchisches Verzeichnis
6.8.1 Dateikonzept
Häufiges Benennungs-Schema für Dateien:
• Pfadnamen (z.B. /usr/jim), absolute, relative Namen
• Traversieren des Verzeichnisbaums
Eingesetzte Algorithmen: u.a.
Beispiel: Unix-Verzeichnis-Baum
• Baumsuche
• Traversieren von Bäumen
• Einfügen/Entfernen von Knoten
6.8.2 Aufgaben des Dateisystems
Bereitstellung von Operationen zur:
• Verwaltung, Speicherung, Benennung
• zur gemeinsamen Nutzung und zum Schutz von Dateien
Systemaufrufe auf Dateien: u.a.
create: Speicher belegen, Verzeichniseintrag anlegen
delete: Eintrag in Verzeichnis ungültig, Speicher freigeben
open: Eintrag in open-file Tabelle des BS-Kerns
close: im System belegter Tabellenplatz wird wieder freigegeben
read: lesen der aktuellen Dateizeigerposition, Aufrufer muss
Datenmenge und Puffer angeben
z.B. int read(int fd, char *puffer, int max_n)
6.8.2 Aufgaben des Dateisystems
File System API-Aufrufe unter Windows und Vergleich mit UNIX
6.8.3 Dateisystem Implementierung
Speicherung und Verwaltung von Dateien auf Platte
• Repräsentation der Dateien durch Dateideskriptoren
• Realisierung von Dateien durch Blöcke
• Datei-Deskriptor: Datenstruktur pro Datei
• Dateityp, Länge der Datei, Plattenblöcke
Beispiel: 64 Byte inode (Unix)
owner joe, uid
group student, guid
type regular file
perms rwxr-xr-x
accessed Feb 12 1999 3:00 P.M.
modified Feb 11 1999 10:16 A.M.
Adressen der 10 ersten Plattenblöcke
einfach indirekt
zweifach indirekt
dreifach indirekt
Verweise auf
Plattenblöcke
.
.
.
Wo, wie findet man was auf der Platte?
Dateiverwaltung/-speicherung auf dem Plattenspeicher:
• Inhaltsverzeichnis des Datenträgers (hier Platte)
• Inhaltsverzeichnis (z.B. Superblock unter Unix) befindet sich an fest
definierter Position auf der Platte
 Typisches Plattenlayout: MBR: Master Boot Record
MBR-Code lädt Inhalt des Boot-Blocks der aktiven Partition
Freispeicherverwaltung:
• Verwaltung aller freien
Speicherbereiche der Platte
• Datenstrukturen: u.a.
(1) verkettete Liste freier Blöcke
(2) Bitmap: Platte mit n Blöcken:
n-Bits zur Verwaltung
Verwaltung der Datenblöcke einer
Datei:
als Zusammenhängende Folge von
Plattenblöcken (Run)
Bsp.: CD-ROM Dateisystem, DVD
Frage: Vorteil/Nachteil?
Ziel: Fragmentierung vermeiden!
Verkettete Liste:
erstes Wort eines Blockes wird als Verweis auf nächsten Block interpretiert.
Problem?
Idee: Verzeigerung nicht in jedem Block, sondern in Extra-Tabelle
File Allocation Table (FAT)
(MS-DOS, von Windows-BS, optional auch von Linux unterstützt)
• Pro Plattenblock ein Eintrag in Tabelle
• Eintrag wird über Blocknummer indexiert
• Verzeichnis-Eintrag: Blocknummer des ersten Blocks (z.B. 217)
• FAT-Eintrag verweist auf nächsten Block bzw. Block Cluster
Extra Tabelle
Beispiel:
FAT-Struktur für
Datei bestehend
aus den Blöcken
217, 618 und 339
File Allocation Table
Vorteil:
• Datenblöcke werden voll ausgenutzt,
• Verkettung der Blöcke erfolgt über FAT
• Random Access auf Blöcke ist möglich; wirklich? Was genau?
Nachteil:
• Tabelle muss vollständig im Speicher gehalten werden
• Beispiel: 20 GB Plattengröße und 1KB Blockgröße:
• Tabelle mit 20 Millionen Einträgen, pro Eintrag mind. 4 Byte
• Tabelle der Größe 60MB bis 80 MB notwendig, resident im HS!
Bem.: FAT wird wegen seiner Einfachheit häufig in mobilen
Datenträgern und eingebetteten Systemen eingesetzt.
Beispiele: USB-Sticks, Digicams, iPods, Disketten
Ziel: Nicht eine große, sondern viele kleine Tabellen
Index-Block (Tabelle) pro Datei:
• Tabelle: Attribute, Plattenadressen von Dateiblöcken
• erste Blöcke werden direkt in Tabelle gespeichert, direkter Block-Zugriff bei
kleinen Dateien
• größere Dateien über Indirektionsstufen, baumartig
 Beispiel: inode in Unix
• Verzeichnis-Eintrag
der Datei enthält
Adresse des IndexBlocks der Datei
• Zugriff auf j-ten
Block:
mit Index j in den
Index-Block
Bislang betrachtet: Verwaltung der Blöcke einer Datei
Jetzt: Verwaltung der Dateien eines Verzeichnisses
Implementierung von Verzeichnissen:
• Vor dem Lesen einer Datei: Öffnen notwendig
• BS verwendet den Pfadnamen, um den zur Datei gehörigen Verzeichniseintrag
zu finden.
• Eintrag enthält die Informationen zum Auffinden der benötigten Plattenblöcke der
Datei
Varianten:
• Plattenadresse der gesamten Datei,
falls diese zusammenhängend gespeichert wurde
• die Nummer des ersten Blocks: Verfahren mit verketteten Listen
• Verweis auf den Index-Block, Nummer des i-nodes
Beispiel: UNIX-Dateisystem
Datenstruktur des UNIX-Kerns
• Prozesslokale Datei-Deskriptor-Tabellen,
• Open-File Tabelle,
• I-Node Tabelle, nur 1 Eintrag für jede Datei
Plattenlayout:
•
Block 0 enthält meist den Code zum Booten des Systems
•
Block 1: Superblock mit Layout-Informationen:
Anzahl der i-nodes, Anzahl der Plattenblöcke,
Anfang der Liste der freien Blöcke
•
Falls Superblock zerstört: Datei-System nicht lesbar
•
Suchen nach Datei george im Verzeichnis /usr,
mit deren i-node kann das Verzeichnis /george gefunden
•
und in ihm nach mbox gesucht werden
•
die i-node dieser Datei wird in den Speicher gelesen und
dort gehalten, bis die Datei wieder geschlossen wird
•
Zusammenfassung der Schritte der Namensauflösung
•
/usr/george/mbox (siehe nächste Folie)
Beispiel (Unix) : Suche nach Datei /usr/george/mbox
Wurzelverzeichnis
i-node 7
Deskriptor für
/usr
Block 132
/usr
i-node 26
für
/usr/george
Block 406
/usr/george
2
.
..
3
bin
4
dev
5
lib
6
etc
26 george
81
Proj
7
usr
tmp
45
17
src
1
8
Modus
Größe
Uhrzeiten
132
1
.
..
19
bill
30
joe
6
51
Modus
Größe
Uhrzeiten
pat
sam
Lokalisieren des Wurzelverzeichnisses /
(dies steht an fester Stelle auf der Platte)
Suchen nach usr im Wurzelverzeichnis
406
26
6
.
..
64
Lehre
92
Buch
60 mbox
6.8.4 Dateischutz (protection)
Datei/Verzeichnis als zu schützende Objekte
• Rechte an (Zugriffsoperationen auf) Dateien: idR
lesen (r), schreiben (w), ausführen (x)
Nutzung von Dateien: Benutzer, Prozesse, Benutzergruppe:
• das sind die Subjekte, die Zugriffe ausführen
Notwendig:
• Rechtevergabe: Festlegung: wer darf was wann:
über Zugriffskontrolllisten (ACLs) und/oder Capabilities
• Kontrolle der Berechtigung von Zugriffen ist die
Aufgabe des Dateisystems
Zugriffskontrolllisten, ACL (Access Control List)
• listenartig organisierte Datenstruktur
• jedem Objekt (hier Datei) ist eine ACL zugeordnet
• Jeder Listeneintrag identifiziert: ein Subjekt und die Rechte, die das
Subjekt an dem Objekt besitzt
• Häufig: Wild Cards als Platzhalter verwendbar
z.B. (Joe, *, rw),
(*,stud,r)
• Zugriffskontrolllisten sind Datei-Attribute
z.B. in Unix z.B. in i-node (Dateideskriptor) verwaltet
• Vorteile von ACLs:
• vergebene Rechte sind effizient für Objekte bestimmbar
• Rechterücknahme ist meist effizient realisierbar
• Nachteile: u.a. aufwändig zu kontrollieren
Standard-Unix: einfache Variante einer ACL:
r w x
r w x
r w x
Rechte für alle Anderen
Rechte der Gruppe der Datei
Rechte des Datei-Eigentümers
Dateityp (Datei, Verzeichnis, Gerät)
Dateirechte: in i-node durch BS-Kern verwaltet,
Bem.: i-node liegt im Klartext auf dem Hintergrundspeicher
Datei-Zugriff: zuerst: open-System Call mit Angabe des Zugriffsmodus
Durchlaufen des Pfades (suchen nach i-node)
owner joe, uid
group student, guid
type regular file
perms rwxr-xr-x
accessed Feb 12 1999 3:00 P.M.
modified Feb 11 1999 10:16 A.M.
Adressen der 10 ersten Plattenblöcke
einfach indirekt
zweifach indirekt
dreifach indirekt
ACL als Bestandteil der
i-node unter Unix
Verweise auf Plattenblöcke
.
.
.
Unix-i-node
.
.
.
.
.
.
Beispiel ACL-Konzept unter Windows 2000/XP
• differenzierte ACL mit Berechtigungen bzw. Verboten
für einzelne Benutzer, aber auch für Gruppen
• Berechtigungen/Verbote in separater Datenstruktur, dem
Security Descriptor, gespeichert
• Security Descriptoren aber nicht in Datei-Deskriptor sondern
• in globaler Tabelle, der Master File Table (MFT) verwaltet
• Security Descriptor enthält:
• SID = systemweit eindeutige Security ID des
Besitzers des Objekts und der Gruppe
• DACL = Discretionary ACL: Liste von ACEs
• ACE = Access Control Element mit allow/deny
• SACL = System ACL, spezifiziert die Operationen,
deren Nutzungen zu protokollieren sind
Beispiel: Windows 2000/XP
• ACL-Eintrag: ACE: Rechte (Bitfolge),
Berechtigung (Deny, Allow)
Subjekt (user, group, ..)
z.B. Benutzer Cathy hat die Rechte:
read, write
Fachbereich
Dr. Frederik
Armknecht | 120
Informatik || Prof.
Fachgebiet
Systeme (GRIS) | Prof. Dr. D. Fellner | 120
Zugriffsausweise: Capabilities
• unverfälschtes Ticket: besteht aus Name, Rechten
• Ticket wird vom BS-Kern ausgestellt
• Besitz berechtigt zum Zugriff auf das in dem Ticket
benannte Objekt
• Zeilenweises Implementierung der Zugriffsmatrix
• jedem Subjekt s wird eine Capabilityliste zugeordnet
• Liste enthält Paare: (Objekt_Identifikator, Zugriffsrechte)
Vorteile von Capabilities:
• Einfache Bestimmung der Subjekt – Rechte
• Einfache Zugriffskontrolle: nur noch Ticketkontrolle!
Nachteile:
• Rechterücknahme schwierig, Kopien suchen
• keine Subjekt-Ticket Kopplung, Besitz berechtigt
automatisch zur Wahrnehmung der Rechte
• Objekt -Sicht auf Rechte schwierig: wer darf was!
• in der einfachen Ausprägung ungeeignet für verteilte
Umgebungen, warum?
Heute: Mischformen: ACL und Capabilities in Standard-BS
Beispiel UNIX/Linux (Windows analog)
• Vor Datei-Nutzung: Datei muss geöffnet werden (open)
• Kern prüft anhand der ACL die Berechtigung und
• stellt file-handle (entspricht Capability) für Zugreifer aus
Beispiel: Zugriffskontrolle unter Unix/Linux
Open-System-Call: Angabe des Zwecks op (r, w, x)
Aktionen des Unix Kerns
(1) Laden der i-node der zu öffnenden Datei
(2) Prüfen, ob zugreifender Prozess gemäß der ACL
der Datei zum gewünschten Zugriff op berechtigt ist
(3) Falls o.k. return File – Handle: enthält Information über op
op-Zugriffe auf geöffnete Datei mit File-Handle
Dateisystem führt Zulässigkeitskontrolle durch:
• Kontrolle, ob op-Rechte im Handle vermerkt
6.9 Ein-Ausgabe (I/O-Subsystem)
6.9.1 BS-Aufgaben:
 Kontrolle der E/A-Geräte, Schutz:
 Datentransfer initiieren, steuern, Daten zwischenpuffern,
 Unterschiedliche Geschwindigkeiten anpassen,
 Uniforme Geräteschnittstelle verfügbar machen
 Abstraktion von den geräteabhängigen Details:
 Befehlssätze der Controller, Fehlerbehandlung,
 Übertragungsgeschwindigkeiten, Blockgrößen etc.
Unterschiedliche Geräte-Charakteristika:
 Zeichenstrom bzw. blockweise Übertragung
 Sequentieller oder wahlfreier Zugriff
 Synchron oder asynchron
6.9.1 BS-Aufgaben
typische E/A-Geräte
• Busse: Verbindungen zwischen E/A-Geräten, Prozessor, Speicher
• Kommunikation zwischen E/A-Geräten und Prozessor: über
• Protokolle auf dem Bus und
• Unterbrechungen (Interrupts)
Hardware
Software
Aufgabe: Integration einer Vielzahl unterschiedlicher Geräte
weitere BS-Kern Subsysteme
restliches E/A-Subsystem
SCSI
GeräteTreiber
Tastatur
Treiber
Maus
Treiber
SCSI
GeräteController
Tastatur Maus
Contr.
Contr.
SCSI
Geräte
Tastatur
Maus
...
PCI-Bus Floppy
Treiber
Treiber
ATAPI
Treiber
...
PCI-Bus Floppy
Contr.
Contr.
ATAPI
Contr.
PCI-Bus
...
Floppy
ATAPI
(Platte,
Band)
6.9.1 BS-Aufgaben
Entwurf eines E/A-Systems:
• Charakteristika eines E/A-System sind durch die
zugrundeliegende Technologie bestimmt,
• z.B. Eigenschaften eines Plattenlaufwerks bestimmen, wie die
Platten mit dem Prozessor verbunden werden und mit dem
Betriebssystem interagieren.
• Geräteabhängig müssen unterschiedliche Eigenschaften
wie Zugriffslatenzzeiten oder Durchsatz beachtet werden.
• E/A-Leistungsverhalten ist abhängig von
• technischen Geräte-Charakteristika,
• der Verbindung vom/zum E/A-Gerät,
• der Speicherhierarchie und
• dem Betriebssystem.
6.9.1 BS-Aufgaben
Aufteilung von EA/-Aufgaben auf Abstraktionsschichten:
• Hardware: Gerät und Controller
• Low-level BS-Schicht: Interrupt-Handling
• Geräte-Treiber, Geräteabhängige Software
• Geräteunabhängige Schicht und I/O-Schnittstelle
Bearbeitung eines I/O-Auftrages über die verschiedenen
Schichten hinweg:
I/O-Antwort
I/O-Anfrage
Benutzer-Prozess
Geräte-unabhängige
Software
I/O-Aufruf
Naming, Prüfung, ...
Geräte-Treiber
Interrupt-Handler
Treiber aufwecken
wenn I/O beendet
Controller
Gerät
Ausführung der
I/O-Operation
6.9.2 I/O Hardware
Klassen von Geräten
(1) Speicher (Platten, Bänder)
(2) Übertragungsgeräte: Netzwerkkarten, Modems
(3) Benutzungsschnittstelle: Bildschirm, Tastatur, Maus
Gemeinsame Charakteristika, Konzepte
• Kommunikation zwischen Gerät und Rechner über
Ports (Kommunikationsendpunkte), z.B. seriell
• Bus-Verbindungen mit Bus-Protokollen
• Controller: elektronische Komponenten
• I/O-Befehle kontrollieren die Geräte
• Geräte besitzen Adressen: Nutzung durch I/O-Befehle
oder Memory Mapped I/O
Plattenstapel
Spuren
(tracks)
Beispiel: Festplatte
•
•
•
•
Platte
(platter)
1–15 Platten
2 beschreibbare Oberflächen
Durchmesser: 1 – 8 inches
Rotationsgeschwindigkeit:
3.600 – 15.000 U/min.
• je 1000 – 5000 Spuren
(konzentrische Kreisscheiben)
• je Spur 64 – 200 Sektoren
(Sektorgröße: 1kB)
Sektoren
(sectors)
Beispiel: 1 GB
eine Spur
1 inch = 2,54 cm

Zum Lesen oder Schreiben müssen die Lese-/Schreib-Köpfe
(read/write heads) über die korrekte Position gefahren werden.
 Die R/W-Köpfe für jede Oberfläche sind miteinander verbunden und
bewegen sich gemeinsam.
Dreistufiger Zugriff auf Daten der Festplatte:
1. Positionierung des R/W-Kopfes über der richtigen Spur (seek);

Zeitaufwand zur Positionierung: Suchzeit (seek time) (Latenz)
2. Warten, bis der korrekte Sektor unter den R/W-Kopf rotiert ist;

Rotationslatenzzeit, rotational latency/delay
3. Plattenzugriff (disk access): Transferzeit (transfer time)

Zeitbedarf um einen Block von Bits zu transferieren
Platten-Controller: Steuerung der Festplatte und des Transfer
zwischen Festplatte und Hauptspeicher (Dauer: controller time)
Antwortzeit der Festplatte = Warteschlange + Controller- +
Positionierlatenzzeit + Rotationslatenzeit + Transferzeit
1.
Positionierlatenzzeit:
 Summe der Positionierlatenzzeiten für alle möglichen Positionieranfragen /
Anzahl aller möglichen Suchanfragen
 durchschnittliche Positionierlatenzzeiten ca. 8 ms, mit Abweichungen bis zu 33% wegen der Lokalität von Verweisen auf Daten auf der
Festplatte
2.
Rotationslatenzzeit
 durchschnittlicher Wert ist halbe Rotationsdauer, z.B.
 0.5 / (7.200 U/min) = 0.5 / (7.200/60 U/s) = 4,2 ms / 0,5 U
3.
Transferzeit ca. 1 Sektor pro ms (d.h. 5 – 15 MB/s)
6.9.3 Geräte-Controller
Ein E/A-Gerät besteht typischer Weise aus einer
mechanischen und einer elektronischen Komponente
Controller (Adapter): die elektronische Komponenten
• 2 Schnittstellen
(1) zum Gerät z.B. SCASI (Festplatte), VGA (Monitor)
(2) zum Prozessor/Speicher idR über Systembus
• Signale an E/A-Gerät: Auslösen von Aktionen, z.B. Kopf-Position.
• konvertieren sequentieller Bitströme in Datenblöcke
• Durchführung von gerätespezifischen Fehlerbehandlungen
E/A-Controller
E/A-Gerät
Puffer
Steuersignale CPU/
E/A-Daten
z.B. „Ack“, „ReadReq“,
„DataRdy“, „Send“, „Error“ ...
Fachbereich Informatik | Fachgebiet Graphisch-Interaktive Systeme (GRIS) | Prof. Dr.
D. Fellner | 134
Signale
Speicher
Klassen von Controllern:
• Controller für seriellen Port:
• einfacher Geräte-Controller, Chip (oder Bestandteil)
• kontrolliert die Signale auf den Leitungen des Ports
• Kommunikation über serielle Leitungen (Unix: /dev/tty1,
Windows: COM1, COM2 bei RS-232 Terminals)
• Controller für parallele Ports:
• Kommunikation über parallele Busse
• UART (Universal Asychronous Receiver and Transmitter)
• Kombination: serielle Leitung zum Endgerät und
• paralleler Bus zum Speicher
• Direct Memory Access (DMA) Controller
• die meisten Systeme verfügen über DMA
Kommunikation zwischen E/A-Controller und CPU/Hauptspeicher:
• Verständigung über Beginn eines Sende-/Empfangsvorgangs mit
Hilfe eines Status-Wortes, das in Flags anzeigt, ob Controller
bereit zum Senden oder Empfangen ist
• „Programmierte E/A“, falls CPU in häufigen, regelmäßigen
Abständen Status des E/A-Geräts abfragt.
• Nach Beginn der Übertragung leert bzw. füllt der E/A-Controller
seinen Puffer im Hauptspeicher und kommuniziert gleichzeitig mit
den beteiligten Endgeräten.
• Bei langsamen E/A-Geräten wird CPU dadurch unnötig lange
blockiert.
Lösung: Konzept der „Interrupt“-gesteuerten E/A
Kommunikation mit Controller über Controller-Register
BS (konkret: die jeweiligen Geräte-Treiber) hat direkten Zugriff auf
Controller-Register
E/A-Gerät
CPU
Register
Puffer
Controller
BS-Kern
Geräte-Treiber
Interrupt-gesteuerte Kommunikation zwischen Controller, CPU
• CPU besitzt spezielle Leitung: Interrupt-Request line
Kommunikation zw. Controller und CPU:
• Nach jeder Befehlsausführung: CPU prüft den Status der
Interrupt-Leitung
• Sobald bestimmtes Ereignis auftritt (z.B. „Controller bereit zum
Senden“) wird ein spezielles Unterbrechungs-Signal erzeugt
• Falls Signal auf Leitung:
• Interrupt: Sichern des aktuellen Ausführungskontextes,
• Springen zur Interrupthandler-Routine (IR)
• IR: ermittelt den Unterbrechungsgrund, führt die Behandlung durch
und nach Return-from-Interrupt nimmt CPU den Zustand
vor der Unterbrechung wieder auf.
Interruptgesteuerte
I/O
6.9.4 Geräte-Treiber (device driver)
Sehr viele unterschiedliche Geräte/Controller mit
spezifischen Eigenschaften
• z.B. Maus: Mausbewegung, Richtung, Entfernung
gedrückte Buttons, etc.
• z.B. Platte: Zylinder, Sektor, Leseschreibkopf, Motor, etc.
• bei einer direkten Zusammenarbeit: BS mit GeräteControllern: BS müsste eine Vielzahl von
unterschiedlichen Geräte Charakteristika beherrschen
Lösung:
• Treiber-Software als geräteabhängige Teile des BS
• Abstrahieren von Unterschieden
6.9.4 Geräte-Treiber
Treiber sind (heute meist dynamisch ladbare) Kern-Module, die die
gerätespezifischen Details kapseln
• Aufgabe:
• verstecken der Unterschiede verschiedener Controller
• vereinheitlichte Nutzungsschnittstelle für die geräteunabhängige
BS-Schicht
• Funktion
• akzeptiert Befehle aus der hardwareunabhängigen Schicht und
transformiert sie in eine Folge von Controller- Befehlen und
aktiviert den Controller über dessen Register
Beispiel Plattentreiber:
• kennt die Register des Platten-Controllers
• kennt die Controller-Befehle, Parameter etc.
6.9.4 Geräte-Treiber
Beispiel: Auftrag an Platten-Treiber
Treiber:
• lokalisiert die geforderten Blöcke auf der Platte,
• prüft, ob der Motor läuft,
• positioniert den Schreib-Lesekopf, ...
Nach Beendigung der Controller-Aktivitäten:
• Treiber prüft auf Fehler
• reicht ggf. Blöcke an die höhere Schicht weiter und
• versorgt den ursprünglichen Anfrager mit Statusinformationen
Vorteile der Trennung Treiber – Controller?
6.9.5 Geräteunabhängige Software
Hauptaufgaben: Scheduling, Pufferung, Kontrolle, Naming
I/O-Scheduling:
• Verwaltung von I/O-Warteschlangen für Geräte
• Neu-Ordnung von Aufträgen,
• Antwortzeiten optimieren
Pufferung: u.a.
• Angleichen unterschiedlicher Bearbeitungsgeschwindigkeiten
(z.B. zwischen Modem und Festplatte)
• Angleichen unterschiedlicher Block-Größen
Kontrolle der Zugriffe auf Geräte
• Beispiele: MS-Dos: keinerlei Schutz,
Unix:
Zugriffsrechte analog zu Dateischutz
Geräte-Benennung
• Abbildung symbolische Geräte-Namen auf Identifikatoren
• Beispiel UNIX:
• /dev/tty0 identifiziert eine i-node
• die i-node enthält die major device number über die wird der
zuständige Treiber lokalisiert,
• über minor device number in i-node: Gerät identifiziert
Index in Treiber-Tabelle: u.a. I/O-Portadresse oder Memory Mapped
Adresse des Gerät-Controllers
Fehlerbehandlung
• viele Fehler sind Geräte-abhängig, nur von den Treibern bearbeitbar,
wenn nicht bearbeitbar: Treiber meldet Fehler an BS
• kontextabhängige Bearbeitung, Beispiel?
Beispiel: Ausführung eines blockierenden read-Aufrufs:
oBdA Verwendung eines bereits geöffneten Files
1. Der BS-Code zur Bearbeitung des Aufrufs:
• überprüft die Korrektheit der übergebenen Parameter
• und prüft, ob die Eingaben bereits im Cache vorliegen
Falls ja, dann Daten sofort an Prozess weiterleiten (Ende)
2. Anderenfalls I/O-Zugriff auf ein E/A-Gerät
• Prozess wird aus Bereit-Warteschlange der CPU entfernt
• und in Warteschlange des benötigten Geräts eingeordnet.
• Aufruf an den Geräte-Treiber weiterleiten
3. Treiber:
• Allokation von Speicher im Kern-Bereich für Daten
• Treiber sendet Befehle an den Controller
4. Controller kommuniziert mit Gerät, um die Operation auszuführen.
5. Falls der Transfer über DMA-Controller abgewickelt wird:
DMA erzeugt Interrupt, wenn Transfer beendet
6. Interrupt-Handler behandelt Interrupt und signalisiert ihn an Treiber
7. Treiber empfängt Signal,
• bestimmt um welchen Aufruf es sich handelt,
• klärt den Status des Aufrufs und
• signalisiert die Beendigung des Aufrufs
8. I/O-Subsystem transferiert Daten in den Adressbereich des
aufrufenden Prozesses
9. Prozess-Blockierung wird beendet, wartet auf CPU
6.10 Busse (spezielle E/A-Geräte)
Busse sind Kommunikationsverbindungen zwischen mehreren
Teilsystemen, die gemeinsame Leitungen verwenden.
Vorteile:
• Neue Geräte können einfach integriert werden.
• Geräte können zwischen verschiedenen Computersystemen mit
demselben Bus-Typ einfach ausgetauscht werden.
• Kosteneffizient, da ein Satz Verbindungen mehrfach genutzt wird.
Nachteile:
• Bus erzeugt Kommunikations-Flaschenhals (bottleneck), der den
maximalen E/A-Durchsatz beschränkt.
(Hohe Prozessorleistung erfordert hohen E/A-Durchsatz.)
6.10 Busse
 Maximale Bus-Geschwindigkeit durch physikalische Faktoren bestimmt:
 Länge der Busse und Anzahl der angeschlossenen Geräte
 Techniken zur Verbesserung des Bus-Leistungsverhaltens können sich
gegenseitig negativ beeinflussen.
 Beispiel: Möglichkeiten zur Erhöhung der Bus-Geschwindigkeit
 Erhöhung der E/A-Datenraten durch Erhöhung der Bus-Bandbreite
(z.B. durch größere Daten-Blöcke )
 Erhöhung der E/A-Datenrate führt tendenziell zu einer erhöhten
Verzögerung bei den Antwortzeiten!
Bus sollte:
(1) Schnellen Zugriff auf das Medium ermöglichen
(2) Hohe Bandbreite bieten und
(3) Universell sein
6.10 Busse
Allgemeines Design: Trennung Steuerung, Daten
Ein Bus enthält im allgemeinen
 einen Satz von Steuerleitungen (control lines)
 zur Anforderung/Bestätigung von Signalen
 zur Indikation des Typs an Information in den Datenleitungen
 einen Satz von Daten- und Adressleitungen (data lines)
 für Daten, Kommandos oder Adressen
 Beispiel: Festplatte möchte Daten aus einem Sektor in den
Hauptspeicher schreiben.
 Datenleitungen enthalten die Zieladresse im Hauptspeicher
und den aktuellen Datenwert.
 Steuerleitungen zeigen an, welcher Typ von Information in den
Datenleitungen des Busses zu jedem Zeitpunkt des Transfers
enthalten ist.
6.10 Busse
 Typische Bus-Transaktion besteht aus zwei Teilen:
 Senden der Adresse und Senden oder Empfangen der Daten
 Definition der Bus-Transaktionen aus Sicht des Prozessors:
 Input-Operation: Transfer von Daten aus einem Gerät zum Hauptspeicher, wo
Prozessor lesen kann.
 Output-Operation: Transfer von Daten aus dem Hauptspeicher, Beispiel:
Control lines
Memory
(1) Steuerleitung enthält
Leseanforderung an Hauptspeicher,
Datenleitung enthält Adresse
(2) Hauptspeicher greift
auf Daten zu.
Data lines
Processor
Disks
Control lines
Memory
Data lines
Processor
Disks
(3)
Hauptspeicher transferiert Daten
über Datenleitungen &
Memory
signalisiert, dass Daten verfügbar sind
Control lines
Data lines
Disks
Processor
6.10 Busse
Kommunikation auf Bussen:
Busse können synchron oder asynchron arbeiten.
Synchron arbeitende Busse:
 einfacher zu realisieren
 Alle angeschlossenen Komponenten müssen mit der gleichen
Geschwindigkeit arbeiten.
 Da z.B. Prozessor im allgemeinen schneller als Festplatte arbeitet,
müssen Unterschiede durch geschickte Taktung ausgeglichen werden:
 Uhrtakt in den Steuerleitungen
 Verwendung eines festen Kommunikationsprotokolls relativ zum
Uhrtakt.
6.10 Busse
Asynchron arbeitende Busse:
 Prozessor kann seine Taktperiode an die Geschwindigkeit der Einheit
anpassen, mit der er gerade kommuniziert.
 aufwändigere Realisierung:
 Koordination der Datenübertragung zwischen Sender und Empfänger mit
Handshake Protokoll
(Bei Input: E/A-Gerät/ bei
Output: Hauptspeicher) zeigen
damit an, daß Datenwort bereits
in Datenleitungen
Zusätzliche Steuerleitungen:
Zeigt LeseAnforderung an
Hauptspeicher an
(Adresse zugleich
in Datenleitung).
Zur Bestätigung der
ReadReq- und
DataRdy-Signale
der Gegenstelle
ReadReq
1
3
Data
2
2
4
6
4
Ack
DataRdy
5
7
6.10 Busse
Beispiel: 7 Schritte zum Lesen eines Wortes aus Hauptspeicher und
Empfangen in einem E/A-Gerät: Start: E/A-Gerät setzt ReadReq-Signal
und stellt Adresse in Datenleitung
1. Sobald Hauptspeicher ReadReq-Signal feststellt, wird Adresse aus
Datenbus gelesen & Ack als Bestätigungssignal gesetzt.
2. E/A-Gerät stellt Ack-Signal fest & gibt ReadReq- und Daten-Leitungen frei.
3. Hauptspeicher sieht ReadReq niedrig & gibt als Bestätigung Ack-Leitung frei.
4. Hauptspeicher stellt Daten in Datenleitung & erhöht DataRdy.
5. E/A-Gerät sieht DataRdy, liest Daten aus Bus & signalisiert Empfang durch
Erhöhen von Ack.
6. Hauptspeicher sieht Ack, erniedrigt DataRdy & gibt Datenleitungen frei.
7. E/A-Gerät sieht Erniedrigung von DataRdy & erniedrigt Ack, wodurch
Fertigstellung der Transaktion signalisiert wird.
6.10 Busse
Read Req
1
3
Da ta
2
4
6
2
4
A ck
5
7
Da taRdy
6.10 Busse
Zugriff auf Bus
 Bus ist exklusives Betriebsmittel
 Ohne Steuerung der Zugriffe auf den Bus: Verschiedene Geräte versuchen
„gleichzeitig“ Daten- und Steuerleitungen zu belegen
 Lösung: Bus-Master kontrollieren alle Zugriffe auf den Bus.
• Prozessor ist immer Bus-Master, Hauptspeicher ist immer Slave
• Mehrere Bus-Master erfordern Bus-Arbitration (Zuteilung):
• Fairneß sollte gewährleistet sein („keiner darf verhungern“).
• Bus-Arbitration sollte effizient sein (d.h. wenig Zeit kosten).
6.10 Busse
Bus-Arbitration: „Daisy Chain“
Ablauf: 1: Request
2. Warten auf Grant
3. Bus belegen, 4. Release
• Subsystem mit höchster Priorität am Anfang der grant-Kette
• Subsystem mit höherer Priorität unterbricht ggf. das grant-Signal.
• Probleme: u.a.
• Geräte „stromabwärts“ können u.U. verhungern.
• Was, wenn ein Gerät vergißt, ein „release“ zu senden?
• Fehleranfälligkeit, da Ausfall eines Geräts andere weiter unten
behindert.
6.10 Busse (Polling)
• Subsystem, das Bus benutzen möchte, setzt ein Signal auf request•
•
•
•
Leitung.
Bus-Arbiter setzt nacheinander die poll-Leitungen.
Erstes befragtes Subsystem, das eine Anforderung gestellt hat, setzt ein
Signal auf die inhibit-Leitung und nutzt den Bus.
Subsystem gibt danach die inhibit-Leitung wieder frei.
Bus-Arbiter kann im Zyklus fortfahren oder von vorne beginnen.
6.10 Busse
Bus-Arbitration
Lösung 3: verteilte, prioritätsgesteuerte Arbitration
 Jedes Subsystem hat seine eigene Leitung für request-Signale.
 Subsystem kann so erkennen, ob gegenwärtig request eines anderen
mit höherer Priorität vorliegt.
 Falls dies der Fall ist, wird eigene Anfrage zurückgestellt.
 Preis: zusätzliche Leitungen für request-Signale
Lösung 4: verteilte Arbitration mit Kollisionserkennung
 Jedes Subsystem fordert Bus unabhängig an.
 Mehrfache, gleichzeitige Anfragen resultieren in Kollision.
 Kollision muß entdeckt und aufgelöst werden.
 Beispiel: Ethernet-LAN
6.11 Synchronisation
Ziel: Wichtigste Synchronisationsprobleme und Lösungen kennen lernen,
Koordinierung von Abläufen
6.11.1 Hintergrund
• in einem Rechnersystem sind zu einem Zeitpunkt idR >> 50 Prozesse
nebenläufig aktiv
• wie bereits gesehen, können Prozesse während ihrer Ausführung
unterbrochen und zu einem späteren Zeitpunkt wieder fortgesetzt
werden: Interleaving der Ausführungen
Problem: Prozesse besitzen häufig Code-Teile, in denen sie auf
gemeinsame Ressourcen (z.B. globale Variablen) lesend/schreibend
zugreifen, d.h.
• Prozesse konkurrieren um gemeinsame Ressourcen: Konflikte!
Beispiel 1: Gemeinsam genutzte Hardware
Ressource (z.B. Bildschirm)
Prozess 1
boolean c1:=true
while c1 do
Prozess 2
boolean c2:=true
while c2 do
for i=1 step 1 until MAXINT
display (" i " )
do something else
begin ... c1:=false ... end
od
for i=1 step 1 until MAXINT
display (" -i " )
do something
begin ... c2:=false ... end
od
Erwartete Ausgabe?
Mögliche Ausgabe?
Roter Kasten = Kritische Abschnitte, da beide Prozesse auf
den gemeinsam genutzten Bildschirm zugreifen
Beispiel 2: Gemeinsam genutzte Software
Ressource
integer a,b :=1; // gemeinsame Daten für beide Prozesse
Prozess 1
while true do
Prozess 2
while true do
a = a +1;
b = b +1;
od
b = b + 2;
a = a + 2;
od
• Effekt: Inkonsistenz der Daten, irgendwann: a ≠ b
• Fazit: Konzepte zur Synchronisation der kritischen
Abschnitte notwendig: wechselseitiger Ausschluss!
6.11.2 Kritische Abschnitte (critical regions)
Problem:
• Prozesse arbeiten in kritischen Bereichen ihres Codes
(critical region) auf gemeinsamen Ressourcen
Lösung:
• gemeinsame Ressourcen sind als exklusiv nutzbare Ressourcen zu
betrachten und
• für die Dauer der Nutzung der Ressource ist der wechselseitige
Ausschluss (wA; mutual exclusion) zu gewährleisten
6.11.2 Kritische Abschnitte
Anforderungen an eine Realisierung des wA:
1. Kritische Abschnitte sind wechselseitig auszuschließen,
2. keine Annahmen über die Reihenfolge der Ausführung der kritischen
Abschnitte,
3. keine Annahmen über die Ausführungszeiten,
4. kein Prozess darf unendlich lange darauf warten müssen, seinen
kritischen Abschnitt betreten zu dürfen
Gewünschtes Verhalten:
6.11.3 Lösungen für den wA
Hardware- und Software-Konzepte
Hardware-Lösung
• Spezielle atomare Maschinenbefehle:
• Swap: Austausch der Inhalte zweier Worte
z.B. Sun SPARC: compare and swap, Pentium xchg(a.b)
• Test-and-Set (Test-And-Set-Lock (TSL))
z.B. Motorola, Intel 80x86, MIPS R4000
Semantik des TSL-Befehls: TLS RX Lock
• Inhalt von LOCK wird in Register RX geschrieben,
• Wert < > Null wird an Adresse LOCK geschrieben.
• Lesen u. Schreiben von LOCK wird als atomare, unteilbare Operation
ausgeführt.
• Atomarität der LOCK-Zugriffe: CPU sperrt den Speicher-Bus
TSL-Befehl zur Realisierung des wA.: enter und leave-Routinen
• Verwenden einer gemeinsamen Variablen flag zur Koordinierung
• Wenn flag = 0, kann jeder Prozess Variable auf 1 setzen und
dann auf gemeinsamen Speicher r oder w zugreifen.
• Nach Beendigung wird flag wieder auf 0 zurück gesetzt.
Beispiel: Pseudo-Lösung in MIPS-Befehlen
flag: .byte 0
enter: tsl $t0, flag
bnez $t0, enter
jr $ra
leave: lw $zero, flag
jr $ra
# in MIPS R2000 nicht!
# flag nach $t0 kopieren und flag auf 1 setzen
# falls flag ≠ 0
# lock ist bereits gesetzt, zurück zur tsl-Abfrage
# Rücksprung zum Aufrufer
# Eintritt in kritischen Abschnitt
# setze flag auf 0
# Rücksprung zum Aufrufer
Verwendung der TSL-Instruktion (Forts.):
• vor Betreten des kritischen Abschnitts:
Ausführung von enter
• nach Ende des kritischen Abschnitts:
Ausführung von leave
Bekannte Algorithmen: Peterson-Verfahren (hier nicht behandelt)
Schwierigkeiten:
• ständiges, aktives Warten („busy waiting“)
• keine faire Lösung, Prozess kann in Warteschlange verhungern
• nur für kurze, kritische Abschnitte geeignet
Software- Lösungen
Bem.: keine vollständige Auflistung, nur wichtige Konzepte:
Unterbrechungssperre und Semaphore
Unterbrechungssperre
• Operationen: Enable und Disable Interrupt
• Aber: nicht als allgemeine Lösung sinnvoll:
z.B.: beliebiger Benutzer-Prozess schaltet Interrupts ab, und dann?
z.B. bei Multiprozessor-Systemen sinnlose Lösung
• Aber für BS-Code häufig sinnvoll und nützlich:
BS-Kern sperrt Interrupts für wenige Befehle,
z.B. um Listen, Variablen zu aktualisieren
Semaphor-Konzept (Signalmast, Telegraph)
• 1965 von E.W. Dijkstra eingeführt, allgemeines Synchronisationskonzept
• idR implementiert eine Semaphore den wA mit
‚passivem‘ Warten der Prozesse, d.h.
• falls die Ressource nicht verfügbar, wird Prozess blockiert
• wartende Prozesse müssen durch andere Prozesse reaktivier werden,
sie prüfen den Status nicht selber
• Bem.: Semaphor auch mit aktivem Warten möglich
Definition: Ein Semaphor s ist ein Datenobjekt mit
• einer lokalen Integer-Variable, die als Zähler verwendet wird,
• mit 2 auf s definierten Operationen: down(s), up(s)
Bem. Ursprünglich hießen diese Operationen P und V
(aus dem holländischen: P (proberen), V (verhogen))
 Weitere übliche Benennungen: wait, signal
 Um aktives Warten zu vermeiden, werden Prozesse blockiert und in
einer Warteschlange verwaltet
 Sei WL(s) die Warteschlange für das Semaphor s, s_counter deren
Zählvariable, p, q Prozesse
Semantik von down(s):
s_counter:=s_counter-1;
if s_counter <0 then insert p in WL(s) ;
block(p);
Semantik von up(s):
s_counter:=s_counter+1;
if s_counter<=0 then delete q aus WL(s);
wakeup (q);
Genutzt werden die BS-Dienste: block, wakeup
block(p):
- entzieht Prozess p die CPU, p im Zustand wartend
- rettet den Ausführungskontext von p und
- stößt den Scheduler an
wakeup(q): - Prozess q von wartend in Zustand rechenwillig
Wichtig: down, up sind unteilbare, atomare Operationen
Frage: wie Atomarität von down(s), up(s) garantieren?
Antwort: down, up als system calls anbieten durch BS,
 Uni-Prozessor: Disable Interrupts bei Op-Ausführung
 Multi-Prozessor: z.B. Spin-Lock oder TSL-Befehl
Frage: doch wieder busy waiting!
Was wurde überhaupt gewonnen?
Semantik des Semaphors s:
 Falls s_counter = i, i>0, i Prozesse können im kri.Absch. sein
 Falls s_counter = j, j<0, j Prozesse sind in WL blockiert
 Falls s_counter = 0, keiner wartet, maximal erlaubte
Prozessanzahl ist im k.A.
Bem.: Mit Semaphoren: allgemeine Koordinierungsaufgaben
implementierbar, Wechselseitiger Ausschluss ist eine davon
Semaphore zur Realisierung des w.A.:
 Initialisierung s_counter mit 1,
Notation: semaphore wa=1; # wa Name des Semaphors
 Kapselung des kritischen Abschnitts mit down, und up:
Beispiel: Prozess Pi
Bsp.:
....
P1
P2
down(wa);
down(wa)
down(wa)
kritischer Abschnitt
kA
kA
up(wa);
up(wa)
up(wa)
....
obdA Schedule: P1, P2, P3, initial: s_counter = 1
P3
down(wa)
kA
up(wa)
Beispiel: 2 Prozesse P1, P2 und zwei Semaphore S, Q
• S und Q beide mit 1 initialisiert
• Ablauf: obdA erst P1
P1: down(S)
jetzt z.B. Interrupt, Scheduler wählt (irgendwann) P2
P2: down(Q)
Prozess P1
down(S)
P1: down(Q) und nun ?
down(S)
down(Q)
Low-level Konzept!
...
Vorsicht beim Einsatz!
up(S)
Deadlockgefahr!
up(Q)
Prozess P2
down(Q)
down(S)
...
up(Q)
up(s)
Bemerkungen:
• eingeführte Semaphore wird als zählendes
Semaphor bezeichnet (counting), da s_counter
beliebige Integer Werte annehmen kann
Binäres Semaphor, Mutex häufig verwendete Variante
• s_counter nimmt nur die Werte 0,1 an
• Mutex: vereinfachtes binäres Semaphor,
Variable mit 2 Zuständen: locked, unlocked
Mutex ist einfach (z.B. im
user-level bei Thread
Biblioth.)
zu implementieren, falls
TSL-Befehl verfügbar ist
Semaphore unter Unix
lockf
Sperren eines Dateizugriffs
msem_init
Semaphorinitialisierung zum Speicherzugriff
msem_lock
Sperren eines Semaphors (down)
msem_unlock Entsperren eines Semaphors (up)
msem_remove Entfernen eines Semaphors
semctl
Semaphorkontrolloperation
semget Hole Semaphorwert
semop Semaphoroperation
Semaphore unter Windows: u.a.
CreateSemaphore()
OpenSemaphore()
WaitForSingleObject(Sema,TimeOutVal)
ReleaseSemaphore()
Erzeugen
Initialisieren
down(s)
up(s)
6.11.4 Allgemeine Synchronisationsprobleme
Klassische Probleme
Erzeuger-, Verbraucher Problem (Bounded Buffer)
• Leser-Schreiber-Problem
• Speisende Philosophen
• Sleeping
Barber
•...
Beispiel: Erzeuger/Verbraucher-Problem
Problemstellung:
• Erzeuger-Prozess E:
• erzeugt Datenelemente und
• schreibt sie in einen Puffer W.
• Verbraucher-Prozess:
• liest Datenelemente aus dem Puffer W
• und verarbeitet sie.
• Puffer W besitzt endliche, feste Kapazität n,
• Zugriffe auf W müssen w.A. sein
Beispiel aus BS-Umfeld für solche Problemstellungen?
Lösung mit zählenden Semaphoren möglich
1ter Lösungsversuch: mit semaphore wa=1
Erzeuger E :
while true do
begin
>>produziere<<
down(wa);
>>schreibe nach W<<
up(wa);
end
Probleme? Lösungsansatz?
Verbraucher V :
while true do
begin
down(wa);
>>entnimmt aus W, falls Element
vorhanden, sonst warten<<
up(wa);
>>verarbeite<<
end
semaphore wa=1,
zusätzliche Semaphoren: leer = N, voll=0
Erzeuger E :
while true do
begin
>>produziere<<
Verbraucher V :
while true do
begin
down(wa);
down(wa);
>>schreibe nach W<<
up(wa);
>>entnimmt aus W, falls Element
vorhanden, sonst warten<<
up(wa);
>>verarbeite<<
end
end
Erzeuger-Verbraucher-Problem mit 3 Semaphoren

Kapitel 6: Betriebssysteme - Security Engineering Group | TU

Transcription

Similar documents

Mobile Systems: Annual Report 2006

motivation - Philipps-Universität Marburg

Thread - Universität Ulm

ESI Script

Neue Besen kehren gut – die Neuerungen in SQL Server 2008

PG eXplorer

1FolieProSeite

Programmierung der AVR-Microcontroller mit C

Einf uhrung in die Assemblerprogrammierung mit dem MIPS

3 Prozesse und Threads

Fakultät für Informatik Algorithm Engineering (LS 11) 44221

Raspberry Pi – Der praktische Einstieg

Magazin - funwithmusic.de

LESE- PROBE Leseprobe

Implementierung von Dateisystemen

Prozesse

aktuellen Unternehmenspräsentation

Folien - Freie Universität Berlin

Kennzeichnung von Produkten / Labelling of products

Spectrum Pricing – Theoretical Approaches and Practical

2.3 Implementierung von Prozessen

Modulhandbuch v. 16.12.2015 - Ostfalia Hochschule für