2 Prozesse und Threads

Betriebssysteme
Folie 2 - 1
2 Prozesse und Threads
•
•
Programm
−
statische Folge von Anweisungen und Daten
−
befindet sich im Allgemeinen als Datei auf einer Festplatte
−
der Dateiinhalt entspricht den Regeln des Betriebssystems für
ausführbare Programme (exe-Format, elf-Format, ...)
Prozess
−
dynamische Folge von Aktionen (Zustandsänderungen)
−
führt ein Programm auf einem Prozessor aus
−
wird vom Betriebssystem infolge eines Auftrags erzeugt
♦ Eingabe eines Kommandos von einem Benutzer
♦ Aufruf einer Systemfunktion von einem Prozess
−
besitzt zugeordnete Speicherbereiche für den Programmcode,
seine statischen und dynamischen Daten sowie seinen Stack
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 2
Systemfunktionen zum Erzeugen/Beenden eines Prozesses
−
Windows 95/98/NT/2000/XP/... (Win32/Win64-API)
♦ CreateProcess (...)
♦ OpenProcess (...)
♦ ExitProcess (...)
♦ TerminateProcess (...)
−
UNIX
♦ fork ( )
♦ execlp (...), execvp (...), ...
♦ exit (...)
♦ kill (...)
•
Struktur eines Prozesses
Process
Resources
open files
locks
sockets
....
Virtual Address Space
main ()
Text
count ()
count ()
Identity
pid
uid
gid
....
prt_result ()
global_cnt
s_time
...
Data
Heap
Stack
Registers
PC
SP
...
j
i
p_cnt
return address
from count ()
...
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 3
Thread
−
sequenzieller Ausführungsfaden innerhalb eines Prozesses
−
minimaler eigener Kontext
♦ CPU-Registersatz
♦ Stack
♦ Identifikationsnummer, Priorität, ...
•
−
alle Threads eines Prozesses benutzen denselben Adressraum
sowie weitere Betriebsmittel des Prozesses gemeinsam
−
jeder Prozess besitzt mindestens einen (initialen) Thread
Systemfunktionen zum Erzeugen/Beenden eines Threads
−
Windows 95/98/NT/2000/XP/... (Win32/Win64-API)
♦ CreateThread (...)
♦ ExitThread (...)
♦ TerminateThread (...)
−
POSIX Threads (UNIX, ...)
♦ pthread_create (...)
♦ pthread_exit (...)
♦ pthread_kill (...)
♦ pthread_cancel (...)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 4
Java Threads (plattformübergreifend)
♦ Erweiterung der Klasse Thread
♦ Implementierung der Schnittstelle Runnable
♦ Aufruf der Methode start ( ) der Klasse Thread
♦ Aufruf der Methode interrupt ( ) der Klasse Thread
•
Struktur eines Prozesses mit mehreren Threads (multi-threaded
process)
Process
Virtual Address Space
Resources
main ()
open files
locks
sockets
....
Text
count ()
Identity
prt_result ()
pid
uid
gid
....
Data
Heap
main
Registers
Stack
PC
SP
...
Thread
Specific
Data
thread id
priority
...
Thread
Specific
Data
thread id
priority
...
Thread 1
Registers
PC
SP
...
Stack
Thread 2
Registers
PC
SP
...
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Stack
Betriebssysteme
•
Folie 2 - 5
Prozesserzeugung unter UNIX
1) Betriebssystemkern muss eine Umgebung bereitstellen, in der
das Programm ausgeführt werden kann
2) der Prozess besteht aus drei Bereichen:
− instruction segment
− user data segment
− system data segment
3) das Programm wird zur Initialisierung des instruction segments
und user data segments benutzt
(nach der Initialisierung besteht zwischen dem Prozess und dem Programm, das er
ausführt, keine weitere Verbindung)
4) das Betriebssystem legt im system data segment alle erforderlichen Datenstrukturen zur Verwaltung des Prozesses an bzw.
aktualisiert bereits vorhandene Datenstrukturen
(es wird z. B. ein Prozesskontrollblock für den Prozess angelegt und initialisiert, ein
Verweis auf den Prozesskontrollblock in die Prozesstabelle eingefügt und der Prozess
dann in die „bereit“-Warteschlange eingefügt)
5) der Prozess kann weitere Betriebsmittel (mehr Speicher, neue
Dateien, usw.) anfordern, die im Programm nicht vorhanden sind
•
mehrere parallel ablaufende Prozesse können mit demselben Programm initialisiert werden
•
der Betriebssystemkern kann Hauptspeicher sparen, wenn solche
Prozesse ein gemeinsames instruction segment verwenden
(die beteiligten Prozesse können die gemeinsame Nutzung nicht feststellen, da die
Segmente nur Lesezugriffe erlauben)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 6
Prozessverwaltung
−
Prozesse stellen Verwaltungseinheiten bzw. Objekte dar
−
auf einem Multiprozessorsystem können Prozesse parallel
ausgeführt werden
−
auf einem Einprozessorsystem können sie durch eine geeignete
zeitliche Verschachtelung quasi-parallel (concurrent) ausgeführt werden
−
das Betriebssystem unterscheidet Anwendungs- bzw. Benutzerprozesse und Systemprozesse
−
Systemprozesse erbringen Betriebssystemleistungen, die aus
dem Betriebssystemkern ausgelagert wurden
−
Anwendungs- und Systemprozesse werden im Benutzermodus
(user mode) ausgeführt
−
im Benutzermodus sind nur nicht-privilegierte Befehle des
Prozessors erlaubt
−
der Betriebssystemkern wird im Systemmodus (system mode,
kernel mode) ausgeführt, in dem auch privilegierte Befehle des
Prozessors erlaubt sind
−
das Betriebssystem benötigt geeignete Datenstrukturen zur
Verwaltung der Prozesse
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 7
Prozessobjekte unter Windows NT/2000/XP/...
−
Prozessobjekte werden durch den Objektmanager erzeugt und
abgebaut
−
jedes Prozessobjekt enthält einen Kopf, der unter der
Verwaltung des Objektmanagers steht
−
Aufbau des Prozessobjekts
Objekttyp
Prozess
Attribute
Prozess-ID
Access Token
Basispriorität
Prozessorzugehörigkeit
Kontingentbeschränkung
Ausführungsdauer
I/O-Zähler
VM-Arbeitszähler
Exception/Debugging Ports
Beendigungsstatus
Dienste
Prozess erzeugen
Prozess öffnen
Prozessinformationen einholen
Prozessinformationen einstellen
Aktueller Prozess
Prozess beenden
VM reservieren/freigeben
VM lesen/schreiben
Virtuellen Speicher schützen
VM sperren und entsperren
VM-Informationen einholen
Virtuellen Speicher aktualisieren
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 8
2.1 Prozess/Thread-Zustände
•
Prozesszustände und die zugehörigen Zustandsübergänge
new
create
I/O completion,
event occurs,
sleep interval expires
ready
blocked
dispatch
timeout,
yield
running
I/O wait,
event wait,
sleep, ...
terminate
suspend
suspend
exit
resume
suspend
suspended
ready
•
I/O completion,
event occurs,
sleep interval expires
resume
suspended
blocked
Thread-Zustände und -Zustandsübergänge in Java
born
start
I/O completion,
sleep interval expires
ready
blocked
dispatch
timeout,
interrupt,
yield
notify or
notifyAll
wait
I/O wait,
sleep, ...
running
finished
dead
waiting
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
•
Folie 2 - 9
Prozess/Thread-Verwaltung basiert auf Zustandsmodell
−
Grundzustände, erweiterte Zustände, Pseudozustände
−
Übergänge zwischen den Zuständen
−
Prozess/Thread kann einige Zustände im Laufe seines Lebens
mehrfach durchlaufen
typische Grundzustände
−
bereit (Synonyme: rechenwillig, rechenbereit, ausführbar,
ready, runnable)
♦ Prozess/Thread wartet nur auf Zuteilung eines Prozessors
♦ im Allgemeinen gibt es verschiedene Prioritätswarteschlangen
♦ neue Prozesse werden im Allgemeinen am Ende ihrer
Prioritätswarteschlange eingefügt
−
aktiv (Synonyme: rechnend, running)
♦ Prozess/Thread hat einen Prozessor zugeteilt bekommen
♦ auf einem Einprozessorsystem kann sich nur ein
Prozess/Thread in diesem Zustand befinden
−
blockiert (Synonyme: wartend, blocked, waiting)
♦ Prozess/Thread wartet auf ein Ereignis, z. B. Ein-/Ausgabe
♦ im Allgemeinen gibt es für verschiedene Wartebedingungen
verschiedene Warteschlangen
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 10
erweiterte Zustände
−
gibt es z. B. bei vielen UNIX-Systemen
−
suspendiert (Synonyme: ausgelagert, suspended)
♦ Prozess/Thread wurde angehalten und im Allgemeinen auf
externes Speichermedium ausgelagert
♦ häufig über zwei Zustände realisiert: suspendiert blockiert
und suspendiert bereit
♦ warum wird ein Prozess/Thread suspendiert ?
⋅
schlechte Systemleistung wegen kurzfristiger Überlast
⋅
Betriebssystem unterstützt keinen virtuellen Speicher,
sodass ganze Prozesse ein-/ausgelagert werden müssen
⋅
Benutzer will einen Prozess stoppen, aber noch nicht
abbrechen
(bei vielen UNIX-Systemen z. B. mit <Ctrl-z> oder <Strg-z>; Fortsetzung
z. B. mit „fg“ (im Vordergrund) oder „bg“ (im Hintergrund))
♦ wer kann einen Prozess/Thread suspendieren ?
⋅
ein Prozess/Thread (selbst) über entsprechende
Systemfunktionen
⋅
der Benutzer/das „Betriebssystem“
♦ Suspendierung durch Prozess/Thread kann schwerwiegende
Folgen haben
⋅
Blockierung mehrerer Prozesse/Threads, falls der suspendierte Prozess /Thread eine Betriebsmittelsperre hält
⋅
u. U. sogar Deadlock, falls die Funktion zur Fortsetzung
des Prozesses/Threads dieselbe Betriebsmittelsperre
benötigt
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 11
Zombie
♦ Zwischenzustand bevor ein Prozess das System verlässt
♦ Prozess hat seine Aufgabe erledigt und muss nur noch einen
Status an seinen Vaterprozess liefern
♦ Zombie-Prozesse belegen nur noch einen Eintrag in der
Prozesstabelle des Betriebssystems
•
Pseudozustände
−
Beginn (Synonyme: nicht existent, new, born)
♦ „notwendiger“ Zustand, um einen Prozess/Thread in das
System zu bringen
♦ wichtig ist nur der Zustandsübergang
−
Ende (Synonyme: nicht existent, exit, exited, dead)
♦ „notwendiger“ Zustand, um einen Prozess/Thread aus dem
System zu entfernen
♦ wichtig ist nur der Zustandsübergang
•
Zustandsübergänge
−
Beginn ⇒ bereit
♦ neuer Prozess/Thread wird erzeugt
♦ Speicherbereiche und Datenstrukturen für neuen Prozess
anlegen und initialisieren
(z. B. Codesegment, Datensegment, Prozesskontrollblock, ...)
♦ Prozess/Thread in Warteschlange „bereit“ einketten
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 12
bereit ⇒ aktiv
♦ Prozess/Thread wird einem freien Prozessor zugeteilt
♦ letzten Prozess/Thread-Kontext wiederherstellen
♦ Prozess/Thread-Zustand auf aktiv setzen
♦ Prozess/Thread starten
−
aktiv ⇒ bereit
♦ Prozessor wird dem Prozess/Thread entzogen
⋅
Zeitscheibe des Prozesses/Threads ist abgelaufen
⋅
Prozess/Thread höherer Priorität wurde rechenwillig
♦ Prozess/Thread-Kontext retten
♦ Prozess/Thread-Zustand auf „bereit“ setzen und Prozess/
Thread in Warteschlange „bereit“ einketten
−
aktiv ⇒ blockiert
♦ Prozess/Thread muss auf ein Ereignis warten
⋅
Beendigung einer Ein-/Ausgabeoperation
⋅
Beendigung eines erzeugten Prozesses/Threads
⋅
...
♦ Prozess/Thread-Kontext retten
♦ Prozess/Thread-Zustand auf „blockiert“ setzen und Prozess/
Thread in Warteschlange „blockiert“ einketten
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 13
aktiv ⇒ Ende
♦ Prozess/Thread verlässt das System
♦ Aufräumarbeiten durchführen (im Allgemeinen nur bei
Prozessen)
⋅
ggf. offene Dateien des Prozesses schließen
⋅
ggf. andere Betriebsmittel des Prozesses freigeben
♦ (alle) Datenstrukturen und Speicherbereiche freigeben
(im Allgemeinen nur bei Prozessen; einige Datenstrukturen (UNIX System V
Semaphore, Shared Memory, ...) werden nicht automatisch freigegeben)
−
blockiert ⇒ bereit
♦ Ereignis ist eingetreten
♦ Prozess/Thread-Zustand auf „bereit“ setzen und
Prozess/Thread in Warteschlange „bereit“ einketten
−
blockiert ⇒ suspendiert blockiert, bereit ⇒ suspendiert bereit,
suspendiert blockiert ⇒ blockiert, suspendiert bereit ⇒ bereit
(im Allgemeinen nur bei Prozessen; suspendierte Threads werden im Allgemeinen
über Zustand „blockiert“ des Prozesses verwaltet)
♦ nur in Ausnahmefällen (siehe Zustand „suspendiert“)
♦ Prozess/Thread-Zustand ändern und Prozess/Thread in
entsprechende Warteschlange einketten
♦ aufwendig, da Datentransport zwischen Haupt- und Hintergrundspeicher erforderlich
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 14
suspendiert blockiert ⇒ suspendiert bereit
(im Allgemeinen nur bei Prozessen)
♦ Ereignis ist eingetreten
♦ Prozess kann ausgeführt werden, sobald er in Hauptspeicher
geladen worden ist
♦ Prozesszustand ändern und Prozess in Warteschlange
„suspendiert bereit“ einketten
−
aktiv ⇒ suspendiert bereit (nur bei Prozessen)
♦ kommt eigentlich nicht (mehr) vor
♦ könnte benutzt werden, wenn ein Prozess der Warteschlange
„suspendiert blockiert“ mit hoher Priorität rechenwillig wird,
der sehr viel Hauptspeicher benötigt und der aktuelle Prozess
viel Hauptspeicher belegt
♦ Prozesskontext retten
♦ Prozesszustand ändern und Prozess in Warteschlange
„suspendiert bereit“ einketten
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 15
Prioritätsklassen in den Zuständen können über verkettete Listen
realisiert werden, z. B.
−
einfach verkettete Listen
priority
n
first last
count
process
...
0
−
first last
count
process
process
process
ringförmig doppelt verkettete Listen
priority
n
current
count
process
...
0
−
current
count
process
Vor-/Nachteile?
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
process
process
Betriebssysteme
•
Folie 2 - 16
Warteschlangenmodelle für Prozesszustände
−
Modell mit mehreren „blockiert“-Warteschlangen
partially executed
swapped-out processes
(in disk swap area)
swap in
new
process
ready
queue
dispatch
swap out
CPU
...
terminated
process
CPU
time slice
expired
I/O queue
I/O
I/O request
wait for
termination
event
occurs
wait for
interrupt
fork a child
call sleep ()
...
...
blocked queues
−
Modell kann durch „bereit“-Warteschlangen erweitert werden
real-time
processes
ready
queues
system
processes
interactive
processes
dispatch
CPU
...
CPU
batch
processes
process with higher
priority is ready,
time slice expired,
I/O finished, ...
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
terminated
process
Betriebssysteme
Folie 2 - 17
2.2 Prozesskontrollblock
•
das Betriebssystem verwaltet für jeden Prozess einen Prozesskontrollblock, der alle relevanten Informationen über den Prozess
enthält
(Synonyme: Prozesskennblock, Prozesskontext, process control block, task control block
Abkürzungen: PCB, TCB)
•
typische Komponenten eines Prozesskontrollblocks
−
Identifikatoren
♦ Prozessnummer/-name
♦ Nummer/Name des Benutzers, der den Prozess gestartet hat
♦ Gruppennummer
−
Stellung in der Prozesshierarchie
♦ Prozessnummer des Vaterprozesses
♦ Prozessnummern der Sohnprozesse
−
Prozessor-Zustandsinformation
♦ Register der Programmierumgebung
(Datenregister, Adressregister, Segmentregister, Indexregister, ...)
♦ Kontroll-, Steuer-, Statusregister
(System-/Benutzer-Stack-Register, Programmzähler, Prozessorstatuswort, ...)
−
Informationen zur Prozesssteuerung
♦ Prozesszustand
♦ Priorität
♦ Informationen zur Interprozesskommunikation
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 18
♦ Zeiger auf Vorgänger und/oder Nachfolger
♦ Zeiger auf Threads des Prozesses
−
Rechte
♦ Zugriffsrechte auf Speicherbereiche, Dateien, ...
♦ Art der erlaubten Prozessorbefehle (privilegiert/nicht privilegiert)
−
Speicherverwaltung
♦ Zeiger auf Segment- und/oder Seitentabellen
♦ Zeiger auf Tabelle mit offenen Dateien
−
Betriebsmittelkonten
♦ Maximalwerte für erlaubte Betriebsmittel
♦ noch verfügbare Kontingente
♦ Abrechnungsdaten
(CPU-Zeiten im System-/Benutzermodus, Anzahl Seitenfehler, ...)
−
•
sonstiges (Uhren, Sperren, ...)
Prozesskontext wird manchmal aufgeteilt in
−
Hardware-Kontext (i. w. Abbild der Prozessorregister)
−
Benutzer-Kontext (i. w. Speicherabbild des Prozesses)
−
System-Kontext (betriebssysteminterne Verwaltungsdaten)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 19
Prozesstabelle enthält Verweise auf Prozesskontrollblöcke
process control block
process identification
process state
process priority
pointer to parent process
pointer to child processes
CPU register
save area
pointers to locate
process's memory
pointers to allocated
resources
...
process
table
...
...
...
NULL
•
Beispiele
−
Linux
♦ Prozesstabelle bis Version 2.2.x (linux/kernel/sched.c)
struct task_struct *task[NR_TASKS] = {&init_task, };
♦
„Prozesstabelle“ ab Version 2.4.x
struct task_struct *init_tasks[NR_CPUS] = {&init_task, };
⇒ Prozesstabelle wurde in Prozessliste je CPU überführt
−
Solaris
♦ struct proc
(/usr/include/sys/proc.h)
♦ struct _klwp
(/usr/include/sys/klwp.h)
♦ struct _kthread
(/usr/include/sys/thread.h)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 20
Verweisstrukturen zur Verwaltung der Sohnprozesse
−
Linux
struct task_struct
parent
p_cptr
p_pptr
p_pptr
p_osptr
youngest
child
p_pptr
p_osptr
child
p_ysptr
oldest
child
p_ysptr
♦ jeder Prozess wird zusätzlich in der Prozesstabelle geführt
(bis Linux Version 2.2.x)
♦ jeder Prozess befindet sich zusätzlich in der Prozessliste
(auch bei Linux bis Version 2.2.x)
−
Solaris
struct proc
parent
p_parent
p_parent
p_psibling
youngest
child
p_sibling
p_child
p_parent
p_psibling
child
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
p_sibling
oldest
child
Betriebssysteme
Folie 2 - 21
Aufgabe 2-1:
a) Definieren Sie die Begriffe Programm, Prozess und Thread.
b) Beschreiben Sie stichwortartig die Prozesserzeugung unter UNIX.
Aufgabe 2-2:
Nennen Sie einige Komponenten des Prozesskontrollblocks und beschreiben Sie stichwortartig, warum die Komponenten vorhanden sind.
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 22
2.3 Dispatcher/Scheduler
•
Scheduler (Ablaufplaner) ist für die zeitliche Ablaufplanung der
Prozesse zuständig
−
erledigt seine Arbeit aufgrund einer gewählten Strategie
−
setzt Anfangspriorität der Prozesse fest
−
kann die Priorität aufgrund des Prozessverhaltens ändern
−
wird z. B. aktiviert, wenn
♦ Prozesse erzeugt/beendet werden
♦ Prozesseigenschaften (z. B. Priorität) geändert werden
♦ eine Zeit abgelaufen ist oder bestimmte Systemfunktionen
aufgerufen werden, die indirekt in die Prozessverwaltung
eingreifen (z. B. zur Koordinierung/Synchronisation von Prozessen)
•
Dispatcher (Prozessumschalter, low-level scheduler) ist für den
Prozesswechsel (task switch, context switch) zuständig
−
muss sehr effizient implementiert werden, da Prozesswechsel im
10 bis 100 Millisekundenbereich vorkommen
−
wird z. B. aktiviert, wenn der aktive Prozess
♦ unterbrochen wird (z. B. Ablauf der Zeitscheibe)
♦ auf ein Ereignis warten muss (z. B. Ende einer Ein-/Ausgabeoperation)
♦ freiwillig auf den Prozessor verzichtet (spezielle Systemfunktion)
♦ endet
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 23
Aufgaben des Dispatchers
−
sichert den (gesamten) Hardware-Kontext des bisher aktiven
Prozesses in dessen Prozesskontrollblock
Die Intel Pentium Familie führt diese Aktion automatisch bei einem Prozesswechsel
durch. Ein Prozesswechsel wird hier z. B. durchgeführt, wenn ein „CALL“-Befehl auf
einen TSS-Deskriptor (task state segment) in der globalen Deskriptortabelle ausgeführt wird.)
−
ändert den Zustand des Prozesses („bereit“, „blockiert“, ...)
−
kettet den Prozess in die entsprechende Warteschlange ein
−
„sucht“ den nächsten zu aktivierenden Prozess
−
ändert den Zustand des Prozesses von „bereit“ auf „aktiv“
−
restauriert den (gesicherten) Hardware-Kontext des Prozesses
(Die Intel Pentium Familie führt diese Aktion automatisch bei einem Prozesswechsel
durch.)
−
„startet“ den Prozess
(Erfolgt im Allgemeinen automatisch durch die Rückkehr aus der Dispatcher-Routine,
da die Prozessorregister nach dem Kontextwechsel den früher unterbrochenen Zustand
des restaurierten Prozesses enthalten.)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 24
Aufgaben des Schedulers
−
Minimierung der Gesamtkosten des Systems
♦ möglichst hoher Durchsatz (Stapelbetrieb)
⇒ Verwaltungsaufwand reduzieren (wenig Prozesswechsel)
♦ möglichst kurze Antwortzeiten (Dialogbetrieb)
⇒ häufige Prozesswechsel
♦ garantierte Antwortzeiten (Echtzeitbetrieb)
⇒ widersprüchliche Anforderungen
⇒ Verhältnis Stapelbetrieb zu Dialogbetrieb wird voreingestellt
⇒ Scheduler kann Stapel- und Dialogbetrieb unabhängig voneinander optimieren
−
sollte die bisherigen Verläufe der Prozesse bei seinen Entscheidungen berücksichtigen
⇒ ordnet die Prozesse/Threads verschiedenen „bereit“Warteschlangen zu
(z. B. aufgrund von Prozessklassen oder Warte- und Rechenzeiten)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 25
„bereit“-Warteschlangen unter Solaris
scheduling
order
class-specific
priorities
first
interrupts
RT max
0
real-time
class (RT)
system
class (SYS)
last
+ TS max
0
- TS max
global
priorities
scheduler
classes
timesharing
class (TS)
process
queues
169 highest
160
159
100
99
60
59
0
lowest
−
der Scheduler konvertiert klassenspezifische Prioritäten in
globale Prioritäten
−
die globale Priorität ist für den Dispatcher maßgebend
−
ein Prozess behält die CPU bis
♦ seine Zeitscheibe abgelaufen ist
♦ er sich selbst blockiert oder endet
♦ ein Prozess höherer Priorität rechenwillig wird
−
Prozesse derselben Priorität benutzen die Round-Robin-Strategie
−
für alle Prozesse gilt im Allgemeinen eine Standard-Zeitscheibe
−
Echtzeitprozesse können prozessspezifische Zeitscheiben haben
−
Prioritäten von Echtzeitprozessen werden durch das System
nicht geändert (können nur vom Benutzer geändert werden)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 26
−
Prioritäten von Systemprozessen werden nur vom Betriebssystem verwaltet (können vom Benutzer nicht beeinflusst werden)
−
Prioritäten von Timesharing-Prozessen
♦ haben benutzer- und systemorientierte Komponente
♦ systemorientierte Komponente wird dynamisch geändert
⋅
Priorität wird erhöht, wenn der Prozess nur einen kleinen
Teil seiner Zeitscheibe nutzt
⋅
Priorität wird erniedrigt bei rechenintensiven Prozessen
⋅
die Länge der Zeitscheibe wird größer je kleiner die
Priorität ist
(wenn Prozesse geringer Priorität aktiv werden, dürfen sie länger arbeiten,
wenn sie nicht durch einen Prozess höherer Priorität unterbrochen werden)
♦ benutzerorientierte Komponente
⋅
kann vom Benutzer zwischen „-TS max“ und „TS max“
geändert werden (im Allgemeinen -20 bis 20; siehe Kommando
„nice“)
⋅
Standardpriorität: 0
⋅
Sohnprozesse erben die benutzerorientierte Priorität
♦ globale Priorität ergibt sich aus den beiden Komponenten
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 27
„bereit“-Warteschlangen unter Windows NT/2000/XP/...
scheduling
order
dispatcher
ready queues
priorities
31
first
process
queues
highest
real-time
16
15
variable
priorities
system
last
−
1
0
lowest
für „variable priorities“
♦ Priorität eines Prozesses/Threads wird jedes Mal erniedrigt,
wenn er seine Zeitscheibe ausgenutzt hat
♦ Priorität eines blockierten Prozesses/Threads wird erhöht
⋅
großer Wert, falls auf Tastatureingabe gewartet wurde
⋅
kleiner Wert, bei anderen Ein-/Ausgaben
♦ Verfahren führt mittelfristig zu einer „Dreiteilung“
⋅
hohe Priorität für interaktive Prozesse/Threads
⋅
mittlere Priorität für E/A-orientierte Prozesse/Threads
⋅
geringe Priorität für rechenintensive Prozesse/Threads
♦ Auswahl eines Prozesses/Threads aufgrund seiner Priorität
und Prozessorzugehörigkeit
⇒
−
falls ein ausgewählter Prozess/Thread aufgrund der Prozessorzugehörigkeit
nicht auf einem freien Prozessor ausgeführt werden kann, wird der Prozess/
Thread mit der nächstgeringeren Priorität ausgewählt
geringste Priorität hat der „idle“-Prozess („system“)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 28
„bereit“-Warteschlangen für Java-Threads
high priority
Priority 10
Priority 9
thr1
Priority 8
Priority 7
Priority 6
normal priority
Priority 5
thr2
thr6
thr3
thr5
...
thrn
Priority 4
Priority 3
Priority 2
low priority
Priority 1
thr4
−
alle Threads starten mit normaler Priorität 5
−
Threads erben die Priorität ihres Erzeugers
−
es gibt Implementierungen mit Zeitscheibenverfahren und rein
prioritätsgesteuerten Scheduling-Verfahren
(Threads derselben Prioritätsklasse werden im ersten Fall im Round-Robin-Verfahren
bearbeitet. Im zweiten Fall können sie solange arbeiten bis sie fertig werden, sich
selbst blockieren oder durch einen Thread höherer Priorität verdrängt werden)
−
manchmal werden mehrere Prioritätsstufen zu einer Prioritätsstufe zusammengefaßt
(unter Solaris 10 und Java 5 gibt es z. B. nur noch die Prioritätsstufen 1-5)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 29
Einteilung der Scheduling-Strategien
−
nicht unterbrechende Verfahren
(Prozess bleibt solange aktiv, bis er sich selbst in den Zustand blockiert versetzt)
−
unterbrechende Verfahren
(dem Prozess kann der Prozessor entzogen werden; notwendig bei Echtzeit-Betriebssystemen)
♦ Prozess kann nur dann unterbrochen werden, wenn der
Prozessor im Benutzermodus arbeitet
(Standard bei älteren UNIX-Systemen)
♦ Prozess kann auch dann unterbrochen werden, wenn der
Prozessor im Systemmodus arbeitet
(notwendig bei Echtzeit-Betriebssystemen)
−
Ausnutzung der Prozessoren bei Multiprozessorsystemen
♦ alle Prozessoren werden genutzt, wenn Arbeit vorhanden ist
♦ einzelne Prozessoren dürfen ungenutzt bleiben, obwohl noch
Arbeit vorhanden ist
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 30
Bewertung von Scheduling-Verfahren
−
CPU-Auslastung (utilization) bzw. Effizienz maximieren
(CPU sollte nach Möglichkeit immer Prozesse ausführen)
−
Fairness
(jeder Prozess erhält einen fairen Anteil der CPU-Zeit; kein Prozess wird beliebig
lange an seiner Arbeit gehindert)
−
Durchsatz (throughput) maximieren
♦ Anzahl der pro Zeiteinheit fertiggestellten Aufträge
♦ schwankt zwischen vielen Aufträgen pro Sekunde und
wenigen pro Tag, Woche oder Monat
(abhängig von der erforderlichen Rechenleistung der Aufträge)
−
Durchlaufzeit bzw. Verweilzeit (turnaround time) minimieren
♦ Zeit zwischen Betreten und Verlassen des Systems für einen
Auftrag
♦ Summe aus Rechenzeit und verschiedenen Wartezeiten
(warten auf CPU in der „bereit“-Warteschlange, auf E/A-Ende in der „blockiert“Warteschlange, usw.)
−
Wartezeit (waiting time) minimieren
♦ Wartezeit in der „bereit“-Warteschlange
♦ nur diese Zeit kann vom Scheduler direkt beeinflusst werden
−
Antwortzeit (response time) minimieren
♦ wichtige Zeitspanne für interaktive Prozesse
♦ Zeit zwischen Eingabe und Reaktion auf Eingabe
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 31
CPU-Auslastung kann bei vielen Systemen grafisch dargestellt
werden
Windows XP
SunOS
Linux: X-osview
Linux: GNOME-Systemmonitor
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 32
mögliche Scheduling-Verfahren
−
First-Come-First-Served (FCFS), First-In-First-Out (FIFO)
(Prozesse werden in der Reihenfolge ihrer Ankunft ohne Unterbrechung bis zu ihrem
Ende bzw. ihrer Blockierung bedient)
♦ das einfachste Verfahren
♦ Implementierung über FIFO-Warteschlange
♦ u. U. große Wartezeiten und damit schlechte Antwortzeiten
♦ im Allgemeinen gute Auslastung der CPU
♦ kann zu langen Warteschlangen mit E/A-intensiven Prozessen führen, wenn ein rechenintensiver Prozess mit wenig
E/A-Operationen immer wieder die CPU blockiert
♦ Beispiel:
Zum Zeitpunkt 0 treffen die Prozesse P1, P2 und P3 ein. Die Rechenzeiten der
Prozesse betragen t1 = 24, t2 = 8 und t3 = 3 Zeiteinheiten resp. Die folgenden
Gantt-Diagramme geben die zeitliche Zuordnung der Prozesse auf einen Prozessor an, wenn sie in der Reihenfolge (P1, P2, P3) bzw. (P3, P2, P1) ankommen.
0
5
10
S1
20
25
P1
0
S2
15
5
P3
10
30
P2
15
20
P2
25
35
P3
30
35
P1
Im Vergabeplan S1 wartet P1 gar nicht, während P2 und P3 24 bzw. 32 Zeiteinheiten warten. Im Mittel warten die Prozesse im Plan S1 (0+24+32)/3 = 56/3
Zeiteinheiten, während sie im Vergabeplan S2 nur 14/3 Zeiteinheiten warten.
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 33
FCFS mit Prioritätswarteschlangen
(Regel: rechenintensive Prozesse erhalten eine geringe Priorität und E/A-intensive
eine hohe Priorität. Prozesse derselben Prioritätsklasse werden in der Reihenfolge
ihrer Ankunft ohne Unterbrechung bis zu ihrem Ende bzw. ihrer Blockierung bedient. Prozesse können durch Prozesse höherer Priorität unterbrochen werden. Der
Scheduler kann die Prioritäten der Prozesse ändern.)
−
Shortest-Job-First (SJF), Shortest-Processing-Time (SPT)
(der Prozess mit der kürzesten Rechenzeit wird als nächster ohne Unterbrechung
bedient; Kenntnis der Rechenzeit ist erforderlich; Prozesse mit gleicher Rechenzeit
werden nach FCFS bedient)
♦ Verfahren ist optimal bezogen auf die mittlere Wartezeit für
eine vorgegebene Menge von Prozessen (Beweis siehe Literatur)
♦ nicht geeignet für kurzfristiges Scheduling, da die Rechenzeiten im Allgemeinen nicht bekannt sind
♦ wird häufig eingesetzt für langfristiges Scheduling im
Stapelbetrieb
(in diesem Fall wird das vom Benutzer vorgegebene Zeitlimit benutzt)
♦ kann auch als „FCFS mit Prioritätswarteschlangen“ implementiert werden
(die Priorität eines Prozesses könnte über den Kehrwert der geschätzten Rechenzeit bestimmt werden ⇒ je mehr Rechenzeit desto niedriger die Priorität)
−
Shortest-Remaining-Time (SRT), Shortest-RemainingProcessing-Time (SRPT)
(im Prinzip SPT mit Unterbrechung, d. h., falls ein neuer Prozess eintrifft, dessen
Rechenzeit geringer ist als die verbleibende Rechenzeit des gerade aktiven Prozesses,
dann wird ein Prozesswechsel durchgeführt)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 34
Round-Robin (RR)
(Der Prozess darf den Prozessor für eine Zeitscheibe benutzen; falls er in dieser Zeit
nicht fertig wird, wird er unterbrochen und am Ende der Warteschlange eingereiht; es
handelt sich hier um ein zyklisches Verfahren ohne Prioritäten)
♦ weit verbreitetes Verfahren für die meisten MultitaskingBetriebssysteme
♦ gleichmäßige Aufteilung der CPU-Zeit auf die Prozesse
♦ Größe der Zeitscheibe bestimmt die Leistung
⋅
zu kleine Zeitscheibe
⇒ hoher Verwaltungsaufwand durch Prozesswechsel
⇒ nominale Systemleistung wird u. U. nicht erreicht,
da Kontextwechsel durchgeführt wird, bevor CacheSpeicher ihre „Warmlaufphase“ überwunden haben
⋅
zu große Zeitscheibe
⇒ nähert sich dem FCFS-Verfahren, da mit zunehmender Zeitscheibe blockierende Systemaufrufe wahrscheinlicher werden
⇒ mittlere Warte- und Antwortzeiten werden größer
−
Shortest-Elapsed-Time (SET), Multilevel Feedback Queue
Scheduling
(im Prinzip RR mit Prioritätswarteschlangen; neuer Prozess wird in die Warteschlange
höchster Priorität eingereiht und erhält hier eine Zeitscheibe; nutzt er die Zeitscheibe
aus, wird er in die Warteschlange nächst niedriger Priorität eingereiht; andernfalls
wird er blockiert und kommt irgendwann wieder in die Eingangswarteschlange; rechenintensive Prozesse sinken schnell in der Priorität)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 35
Aufgabe 2-3:
Die folgenden Prozesse kommen in der Reihenfolge (P1, P2, P3, P4, P5)
zum Zeitpunkt 0 an. Zeichnen Sie die Gantt-Diagramme für die zeitliche
Zuordnung der Prozesse auf einen Prozessor für die Scheduling-Verfahren FCFS, SJF, RR (eine Zeitscheibe entspricht einer Zeiteinheit) und
ein nicht unterbrechendes Verfahren mit Prioritätswarteschlangen (kleine Prioritätsnummer entspricht hoher Priorität). Geben Sie für die verschiedenen Verfahren die Durchlaufzeit, die mittlere Durchlaufzeit, die
Wartezeit und die mittlere Wartezeit der Prozesse an.
Prozess
Rechenzeit
Priorität
(in Zeiteinheiten)
P1
P2
P3
P4
P5
10
1
2
1
5
3
1
3
4
2
Aufgabe 2-4:
Die Prozesse P1, P2, P3, P4 und P5 treffen in dieser Reihenfolge ein. Die
genauen Ankunfts- und Rechenzeiten können der nachfolgenden Tabelle
entnommen werden. Zeichnen Sie die Gantt-Diagramme für die zeitliche
Zuordnung der Prozesse auf einen Prozessor für die Scheduling-Verfahren FIFO, SPT, SRT und RR (eine Zeitscheibe entspricht zwei Zeiteinheiten). Geben Sie für die verschiedenen Verfahren die mittlere Verweilzeit der Prozesse im System an. Ein Prozesswechsel erfolgt nur zu den
ganzzahligen Zeitpunkten 1, 2, 3, …
Prozess
P1
P2
P3
P4
P5
Ankunftszeit
0,0
0,2
1,1
3,1
4,1
Rechenzeit
11
2
6
1
4
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 36
2.4 Prozesssynchronisation
•
Prozesse können folgendermaßen ausgeführt werden
−
zeitlich verschachtelt (quasi-parallel) auf einem Einprozessorsystem
−
zeitlich überlappt (parallel) auf einem Multiprozessorsystem
−
zeitlich verschachtelt und überlappt
(heutiger Standard auf einem Multiprozessorsystem)
•
Beispiel: modifizierender Zugriff auf eine gemeinsame Variable
1. Ausführungsreihenfolge
Prozess/Thread 1
Prozess/Thread 2
liest Wert der Variablen i
erhöht Wert um 1
speichert neuen Wert in i
liest Wert der Variablen i
erhöht Wert um 1
speichert neuen Wert in i
2. Ausführungsreihenfolge
Prozess/Thread 1
Prozess/Thread 2
liest Wert der Variablen i
liest Wert der Variablen i
erhöht Wert um 1
speichert neuen Wert in i
erhöht Wert um 1
speichert neuen Wert in i
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
•
Folie 2 - 37
Problem des obigen Beispiels
−
Fehler kann auftreten, muss aber nicht auftreten
−
Fehler ist schwer reproduzierbar, da abhängig von Nebenbedingungen (z. B. Systemlast)
−
typischer Synchronisationsfehler, wenn ein Prozess einen
anderen im Ablauf überholt (als race condition bekannt)
−
Programmbereiche, in denen solche Fehler entstehen können,
dürfen nicht unterbrochen werden (kritischer Abschnitt, critical section)
Arbeitsweise der Prozesse muss koordiniert werden
−
Koordinierung
♦ Beeinflussung der Abläufe paralleler Prozesse/Threads
♦ Steuerung von Wechselwirkungen (Konkurrenz/Kooperation)
♦ Mittel: Synchronisation/Kommunikation
♦ Ziel: deterministischer Ablauf
(globale Ergebnisse sind unabhängig von der Ablaufreihenfolge der Prozesse)
−
Synchronisation
♦ Ablauf wird in zeitliche Reihenfolge gebracht
♦ Reihenfolge kann zufällig oder vorbestimmt sein
−
Sperrsynchronisation/wechselseitiger Ausschluss (mutual exclusion)
♦ Menge von konkurrierenden Prozessen/Threads um ein
Betriebsmittel
♦ einer wird ausgewählt und alle anderen werden gesperrt
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 38
wechselseitiger Ausschluss wird im Allgemeinen durch Protokolle
realisiert
−
Vorprotokoll sorgt für Auswahl eines Prozesses/Threads
−
Nachprotokoll sorgt für Freigabe des kritischen Bereichs
Process/Thread 1
Process/Thread 2
acquire lock
access data
release lock
acquire lock
access data
release lock
shared
data
acquire lock
access data
release lock
Process/Thread 3
•
Regeln für die Benutzung eines kritischen Abschnitts
1) Sicherheit: Zu jeder Zeit darf sich höchstens ein Prozess innerhalb des kritischen Abschnitts befinden
2) Lebendigkeit: Wenn ein Prozess in einen kritischen Abschnitt
eintreten will, wird ihm dies nach endlicher Zeit gestattet
⇒ jeder Prozess verbringt nur eine endliche Zeit im kritischen
Abschnitt (keine Programmierfehler durch Endlosschleifen, ...)
⇒ das Protokoll garantiert Fairness
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 39
Realisierungsmöglichkeiten für wechselseitigen Ausschluss
−
kurzfristige Deaktivierung des Unterbrechungssystems
(verhindert Unterbrechungen und damit Prozesswechsel; sehr harte Methode, die nur
in Ausnahmefällen benutzt werden sollte)
−
Sperrvariablen (spin locks)
(ihr Wert gibt an, ob der kritische Bereich belegt oder frei ist; sie funktionieren nur
dann effizient und allgemeingültig, wenn sie über einen speziellen, unteilbaren Befehl
der Maschinensprache (z. B. „BSET“ (test a bit and set, Motorola MC68x00 Familie),
„BST“ (bit test and set, Intel Pentium Familie)) realisiert werden; Variablen werden
im Vorprotokoll abgefragt und im Nachprotokoll freigegeben; ggf. muss der Wert im
Vorprotokoll zyklisch abgefragt werden, bis der kritische Abschnitt frei ist (aktives
Warten, busy waiting), sodass Prozessorzeit verschwendet wird; es müssen aufwendige Algorithmen implementiert werden, wenn solche Maschinenbefehle nicht benutzt
werden können)
−
Semaphore
(integrieren eine Variable (eine Art „Ampel“) und eine Warteschlange für Prozesse/
Threads, sodass aktives Warten vermieden wird; die Variable kann vom Typ boolean
bzw. bit sein (binäre Semaphore, mutex) oder vom Typ integer (allgemeine/zählende
Semaphore); Semaphore und die zugehörigen Protokolloperationen sind im Betriebssystem implementiert; die Operationen werden aus der Sicht der Prozesse atomar ausgeführt)
−
Monitore
(sind Bestandteil einer höheren Programmiersprache, sodass der Einsatz vom Compiler überwacht werden kann; stehen nur in wenigen Sprachen zur Verfügung)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 40
2.4.1 Globale Variablen
•
Synchronisation der Prozesse/Threads ohne Betriebssystem-/Compiler-Unterstützung
(in Zukunft wird nur noch der Begriff Prozess benutzt, obwohl die verschiedenen Algorithmen in den Beispielprogrammen tatsächlich über Threads realisiert werden, da sie auf
einfache Weise globale Variablen unterstützen)
•
Zugriff auf ein Betriebsmittel erfolgt in zwei Schritten:
1) Variable auf den Wert Betriebsmittel frei überprüfen
2) a) frei:
Variable auf den Wert Betriebsmittel belegt ändern
und das Betriebsmittel nutzen
b) belegt: warten, bis das Betriebsmittel frei wird
•
zugehöriger Programmausschnitt
...
while (BetriebsmittelZustand == belegt)
{
;
}
BetriebsmittelZustand = belegt;
...
BetriebsmittelZustand = frei;
...
•
/* normales Programm
*/
/* warten
*/
/* Betriebsmittel nutzen
*/
/* normales Programm
*/
leider kann das Problem auf diese einfache Weise nicht gelöst
werden (siehe auch einführendes Beispiel am Anfang des Kapitels 2.4)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 41
möglicher Ablauf
−
das Betriebsmittel sei frei und Programm A sei aktiv
−
nachdem Programm A die while-Schleife erfolgreich durchlaufen hat, wird ein Prozesswechsel durchgeführt
−
als Nächstes wird Programm B aktiviert und durchläuft die
while-Schleife ebenfalls erfolgreich, da Programm A das
Betriebsmittel nicht mehr sperren konnte
−
Programm B sperrt das Betriebsmittel und benutzt es
−
innerhalb der Nutzungsphase wird auch Programm B der Prozessor entzogen und Programm A wird aktiviert
−
da Programm A die while-Schleife bereits erfolgreich durchlaufen hat und nicht weiß, dass ihm zwischenzeitlich der Prozessor entzogen worden ist, belegt und benutzt es das Betriebsmittel
ebenfalls
⇒ die Sperrsynchronisation durch eine globale Variable hat versagt
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 42
Lösung 1 für den wechselseitigen Ausschluss
volatile int turn;
/* Nr. des Prozesses, der kritischen */
/*
Abschnitt betreten darf
*/
int main (void)
{
turn = 1;
COBEGIN
worker1;
worker2;
COEND;
}
/* ========
Hauptprogramm
/* beide Prozesse starten
void worker1 (void)
/*
{
for (;;)
{
while (turn == 2)
/*
{
/*
;
/*
}
/*
kritischer Abschnitt;
turn = 2;
/*
sonstige Arbeit;
/*
}
}
==========
void worker2 (void)
/*
{
for (;;)
{
while (turn == 1)
/*
{
/*
;
/*
}
/*
kritischer Abschnitt;
turn = 1;
/*
sonstige Arbeit;
/*
}
}
==========
•
======== */
Prozess 1
*/
========== */
| Vorprotokoll
|
|
(p2 hat Erlaubnis -> warten)
|
*/
*/
*/
*/
| Nachprot. (p2 Erlaub. erteilen) */
hier kann Proz. u.U. beendet werd.*/
Prozess 2
========== */
| Vorprotokoll
|
|
(p1 hat Erlaubnis -> warten)
|
*/
*/
*/
*/
| Nachprot. (p1 Erlaub. erteilen) */
hier kann Proz. u.U. beendet werd.*/
Code zwischen COBEGIN und COEND wird parallel ausgeführt
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 43
Diskussion der Lösung 1
•
Lösung garantiert wechselseitigen Ausschluss, da Prozess i nur dann
in seinen kritischen Abschnitt eintritt, wenn turn == i ist
•
Lösung ist verklemmungsfrei, da der Prozess, dessen Nummer in
turn gespeichert ist, immer weiterarbeiten kann
•
Lösung stellt sicher, dass kein Prozess am Betreten des kritischen
Abschnitts gehindert wird, falls der unkritische Abschnitt normale
Arbeit nur eine endliche Zeit dauert
⇒ Lösung erfüllt Regeln zur Benutzung eines kritischen Abschnitts
⇒ aus den folgenden Gründen ist sie trotzdem nicht als Lösung des
Problems geeignet
1) die beiden Prozesse müssen ihre kritischen Abschnitte abwechselnd betreten, d. h., ein langsamer Prozess kann einen
schnellen behindern
2) falls Prozess worker1 den kritischen Abschnitt durchlaufen und
für Prozess worker2 freigegeben hat, kann er ihn nie mehr betreten, wenn Prozess worker2 inzwischen z. B. aufgrund eines Fehlers im unkritischen Bereich beendet wurde
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 44
Implementierung des obigen Programms
/* Solution 1 for the synchronization of two concurrent workers
* with global variables.
*
* UNIX:
*
(g)cc [-DSunOS] [-DLinux] [-DIRIX] [-DCygwin]
*
-o glvar_1a glvar_1a.c parallel.c -lpthread
* Windows 95/98/NT/ME/2000/XP/...:
*
cl
/DWin32 /W4 glvar_1a.c parallel.c
(Microsoft)
*
bcc32 /DWin32 glvar_1a.c parallel.c
(Borland)
*
...
*
* File: glvar_1a.c
Author: S. Gross
* Date: 21.08.2007
*
*/
#include
#include
#include
#include
#include
#define
#define
#define
#define
<stdio.h>
<stdlib.h>
<time.h>
<assert.h>
"parallel.h"
NUM_THR
NUM_CYCLES
MAX_NTIME
MAX_CTIME
2
30
4
2
/*
/*
/*
/*
must
# of
max.
max.
(!) be 2
normal/critical cycles
time for normal work
time for critical work
*/
*/
*/
*/
void worker1 (long id);
void worker2 (long id);
/* turn: number of the worker which is allowed to enter the critical
*
section next
* "volatile" is necessary to prevent that modern compilers optimize
* a statement away when its assignment isn't used or that they change
* the sequence of statements which contain this variable.
*/
volatile int turn;
int main (void)
{
ThrID_t thr_id[NUM_THR];
/* ID's of concurrent workers
assert (NUM_THR == 2);
srand ((unsigned int) time ((time_t *) NULL));
/* worker 1 is allowed to enter the critical section first
turn = 1;
/* start concurrent workers
thr_id[0] = parallel ((PtrFunc_t) worker1, 0);
thr_id[1] = parallel ((PtrFunc_t) worker2, 1);
/* wait until all concurrent workers have terminated
join_all (thr_id, NUM_THR);
return EXIT_SUCCESS;
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
*/
*/
*/
Betriebssysteme
Folie 2 - 45
/* Worker processes doing critical and non-critical work.
*
* input parameter:
id
"name" of the worker
* output parameter:
none
* return value:
none
* side effects:
none
*
*/
void worker1 (long id)
{
int i;
/* loop variable
*/
for (i = 0; i < NUM_CYCLES; ++i)
{
printf ("Worker %ld: doing normal work in cycle %d.\n", id, i);
/* simulate some normal work
*/
SLEEP ((unsigned int) rand () % MAX_NTIME);
printf ("Worker %ld: try to enter critical section in cycle %d.\n",
id, i);
while (turn == 2)
{
printf ("Worker %ld: waiting in cycle %d.\n", id, i);
SLEEP (1);
}
printf ("Worker %ld: doing critical work in cycle %d.\n", id, i);
/* simulate some critical work
*/
SLEEP ((unsigned int) rand () % MAX_CTIME);
turn = 2;
/* release critical region
*/
}
}
void worker2 (long id)
{
int i;
/* loop variable
*/
for (i = 0; i < NUM_CYCLES; ++i)
{
printf ("Worker %ld: doing normal work in cycle %d.\n", id, i);
/* simulate some normal work
*/
SLEEP ((unsigned int) rand () % MAX_NTIME);
printf ("Worker %ld: try to enter critical section in cycle %d.\n",
id, i);
while (turn == 1)
{
printf ("Worker %ld: waiting in cycle %d.\n", id, i);
SLEEP (1);
}
printf ("Worker %ld: doing critical work in cycle %d.\n", id, i);
/* simulate some critical work
*/
SLEEP ((unsigned int) rand () % MAX_CTIME);
turn = 1;
/* release critical region
*/
}
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 46
„worker1“ und „worker2“ sind im Wesentlichen identisch, sodass
folgende Vereinfachung vorgenommen werden kann
int main (void)
{
...
/* start concurrent workers
thr_id[0] = parallel ((PtrFunc_t) worker, 0);
thr_id[1] = parallel ((PtrFunc_t) worker, 1);
...
}
void worker (long id)
{
int i;
/* loop variable
*/
*/
for (i = 0; i < NUM_CYCLES; ++i)
{
prt_msg ("Worker", id, "doing normal work in cycle", i);
/* simulate some normal work
*/
SLEEP ((unsigned int) rand () % MAX_NTIME);
prt_msg ("Worker", id, "try to enter critical section in cycle", i);
while (turn != id)
{
prt_msg ("Worker", id, "waiting in cycle", i);
SLEEP (1);
}
prt_msg ("Worker", id, "doing critical work in cycle", i);
/* simulate some critical work
*/
SLEEP ((unsigned int) rand () % MAX_CTIME);
turn = (id + 1) % NUM_THR;
/* release critical region
*/
}
}
void prt_msg (char *name, long id, char *text, int cycle)
{
P (screen);
printf ("%s %ld: %s %d.\n", name, id, text, cycle);
V (screen);
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 47
Lösung 2 für den wechselseitigen Ausschluss
•
anstelle der gemeinsamen Variablen turn wird jedem der beiden
Prozesse worker_i eine globale Variable ci zugeordnet
volatile int c1, c2; /* ci = 0: P. ist im krit. Abschn. o. */
/*
will ihn betreten
*/
/* ci = 1: P. ist im "normalen" Progr.*/
int main (void)
{
c1 = 1;
c2 = 1;
COBEGIN
worker1;
worker2;
COEND
}
/* ========
Hauptprogramm
/* beide Prozesse starten
========= */
*/
void worker1 (void) /* ========== Prozess 1 =========== */
{
for (;;)
{
c1 = 0;
/* | Vorprotokoll (Abschn. reserv.)
*/
while (c2 == 0) /* |
*/
{
/* |
*/
;
/* |
ggf. warten bis Abschn. frei
*/
}
/* |
*/
kritischer Abschnitt;
c1 = 1;
/* | Nachprotokoll (Abschn. freigeben)*/
sonstige Arbeit;
}
}
void worker2 (void) /* ========== Prozess 2 =========== */
{
for (;;)
{
c2 = 0;
/* | Vorprotokoll (Abschn. reserv.)
*/
while (c1 == 0) /* |
*/
{
/* |
*/
;
/* |
ggf. warten bis Abschn. frei
*/
}
/* |
*/
kritischer Abschnitt;
c2 = 1;
/* | Nachprotokoll (Abschn. freigeben)*/
sonstige Arbeit;
}
}
•
diskutieren Sie die Lösung
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 48
Lösung 3 für den wechselseitigen Ausschluss
•
Problem von Lösung 2 soll dadurch behoben werden, dass der
Prozess kurzfristig darauf verzichtet, den kritischen Abschnitt zu
betreten, wenn die globale Variable des anderen Prozesses anzeigt,
dass er im kritischen Abschnitt ist bzw. ihn betreten will
volatile int c1, c2;
/* ci = 0: P. ist im krit. Abschn. oder */
/*
will ihn betreten
*/
/* ci = 1: P. ist im "normalen" Progr. */
int main (void)
{
c1 = 1;
c2 = 1;
COBEGIN
worker1;
worker2;
COEND;
}
/* =========
void worker1 (void)
{
for (;;)
{
normale Arbeit;
c1 = 0;
while (c2 == 0)
{
c1 = 1;
...
c1 = 0;
}
kritischer Abschnitt;
c1 = 1;
}
}
void worker2 (void)
{
...
}
•
Hauptprogramm
========== */
/* beide Prozesse starten
/* ===========
/*
/*
/*
/*
/*
/*
/*
Prozess 1
*/
============ */
| Vorprotokoll
|
|
|
Verzicht auf krit. Abschnitt
|
einen Augenblick warten
|
neuer Versuch
|
/* | Nachprotokoll
/* ===========
Prozess 2
/* analog worker1
diskutieren Sie die Lösung
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
*/
*/
*/
*/
*/
*/
*/
============ */
*/
Betriebssysteme
Folie 2 - 49
Lösung 4: Algorithmus von Dekker
•
Kombination der ersten und dritten Lösung zum wechselseitigen
Ausschluss
volatile int turn,
c1, c2;
int main (void)
{
turn = 1;
c1
= 1;
c2
= 1;
COBEGIN
worker1;
worker2;
COEND;
}
void worker1 (void)
{
for (;;)
{
sonstige Arbeit;
c1 = 0;
while (c2 == 0)
{
if (turn == 2)
{
c1 = 1;
while (turn == 2)
{
;
}
c1 = 0;
}
}
kritischer Abschnitt;
turn = 2;
c1
= 1;
}
}
void worker2 (void)
{
...
}
/* Nr. des Prozesses, der als nächster
/*
den krit. Abschnitt betreten darf
/* ci = 0: P. ist im krit. Abschn. o.
/*
will ihn betreten
/* ci = 1: P. ist im "normalen" Progr.
/* =========
Hauptprogramm
========= */
/* beide Prozesse starten
/* ===========
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
|
|
|
|
|
|
|
|
|
|
|
|
|
/* |
/* |
Prozess 1
*/
=========== */
Vorprotokoll
Prozess 2 hat Prioritaet
-> "hoeflich" sein
Verzicht auf krit. Abschnitt
warten
neuer Versuch
Nachprotokoll
/* ===========
Prozess 2
/* analog worker1
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
=========== */
*/
Betriebssysteme
Folie 2 - 50
Diskussion des Verfahrens von Dekker
•
•
das Verfahren ermöglicht eine korrekte Selbstverwaltung des
wechselseitigen Ausschlusses
−
Lösung 3 wird um die Variable turn aus Lösung 1 ergänzt
−
turn legt (vorab) fest, welcher Prozess im Konfliktfall die höhere
Priorität hat und welcher höflich sein muss
die Probleme der ersten drei Lösungen beruhen darauf, dass ein
Prozess nach jeder Operation unterbrochen werden kann
⇒ Überprüfung der Betriebsmittel-Variablen und ggf. Belegen des
Betriebsmittels muss in einer unteilbaren Operation erfolgen
•
alle Lösungen haben den Nachteil, dass die Prozesse aktiv auf ein
Ereignis warten und damit sinnlos Prozessorleistung verschwenden
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 51
Aufgabe 2-5:
Gegeben sind sechs Prozesse P1, ..., P6 mit den Rechenzeiten
τ1 = 2, τ 2 = 1, τ 3 = 3, τ 4 = 2, τ 5 = 1, τ 6 = 5. Skizzieren Sie für den folgenden Programmausschnitt die Überlagerungsphasen (Aktivitätsphasen)
der einzelnen Prozesse. Zwischen BEGIN und END stehen sequenziell
auszuführende Teile und zwischen COBEGIN und COEND parallel
ausführbare Teile.
COBEGIN
P1;
BEGIN
P2;
COBEGIN
P3;
P4;
COEND
P5;
END
P6;
COEND
Aufgabe 2-6:
Gegeben seien die folgenden Überlagerungsphasen der sechs Prozesse
T1 , ..., T6 . Geben Sie die zugehörige Programmsequenz an. Verwenden
Sie die Sprachelemente BEGIN, END, COBEGIN und COEND.
T6
T5
T4
T3
T2
T1
t
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 52
Beurteilung des Lösungsansatzes „Globale Variable“
1) Programme hängen sehr stark voneinander ab
•
die Lösung muss die Anzahl der nebenläufigen Prozesse berücksichtigen
•
ein unabhängiger, getrennter Programmentwurf ist praktisch unmöglich
2) Verallgemeinerung auf n > 2 Prozesse ist schwierig (existiert aber)
3) es werden ineffiziente, aktive Warteschleifen benutzt (busy waiting)
4) es wird eine gemeinsame Variable turn benutzt, die von allen Prozessen beschrieben wird
•
u. U. Verletzung von Speicherschutzmechanismen
•
nicht geeignet für verteilte Systeme (Rechnernetze), da ein
Prozess auf Rechner A keine Variable auf Rechner B
modifizieren kann
5) fehleranfällig, da der wechselseitige Ausschluss durch den Anwendungsprogrammierer gewährleistet werden muss
⇒ es sind mächtigere Sprachmittel für die Programmierung nebenläufiger Programme erforderlich
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 53
2.4.2 Semaphore
•
Sprachmittel zur Koordinierung paralleler Programme (Dijkstra 1965)
−
stammt aus dem Griechischen: Zeichenträger, Signalmast, optischer Telegraf (z. B. in der Schifffahrt), ...
−
Semaphore sind in verschiedenen Betriebssystemen implementiert (UNIX, Windows NT/2000/XP/..., ...)
−
aktives Warten wird vermieden
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
•
•
Folie 2 - 54
Definition: Ein Semaphor s ist eine Variable, die nur nicht-negative
ganzzahlige Werte annehmen kann
−
manchmal wird die Semaphor-Variable auch so definiert, dass
sie negative Werte annehmen darf
−
intern besteht ein Semaphor im Allgemeinen aus einer
Zählervariablen und einer Warteschlange
erlaubte Manipulationen
−
einmalige Initialisierung der Variablen
−
unteilbare Elementaroperationen P (s) und V (s)
Bemerkungen
1) allgemeine Semaphor-Variablen werden z. B. verwendet, wenn
von einem Betriebsmittel mehrere identische Exemplare vorhanden sind
2) binäre Semaphor-Variablen können nur die Werte 0 und 1 annehmen und können besonders einfach implementiert werden
(werden häufig auch Mutex-Variablen (mutual exclusion) genannt)
3) die Auswahlstrategie für die wartenden Prozesse bei der VOperation ist im Allgemeinen FIFO (diese Strategie ist aber
nicht zwingend vorgeschrieben)
4) Semaphore und ihre Operationen sind normalerweise Bestandteil
des Betriebssystemkerns, sodass die Prozesszustände einfach
durch die Prozessverwaltung geändert werden können
5) Es darf nur eine Initialisierung des Semaphors s im Programm
erfolgen, weitere Zuweisungen oder Testoperationen mit s sind
verboten.
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 55
Systemfunktionen für Semaphore
−
Windows 95/98/NT/2000/XP/... (Win32/Win64-API)
Operation
Objekt erzeugen
−
Critical Section
Mutex
(prozessintern)
(prozessübergreifend)
InitializeCriticalSection (...)
Semaphore
CreateMutex (...)
CreateSemaphore (...)
OpenMutex (...)
OpenSemaphore (...)
initialisieren
-
-
beim Erzeugen
P (...)
EnterCriticalSection (...)
WaitForSingleObject (...)
WaitForSingleObject (...)
V (...)
LeaveCriticalSection (...)
ReleaseMutex (...)
ReleaseSemaphore (...)
Objekt freigeben
DeleteCriticalSection (...)
CloseHandle (...)
CloseHandle (...)
UNIX
Operation
System V IPC
POSIX IPC
POSIX IPC
(namenlose Semaphore)
(Semaphore mit Namen)
Objekt erzeugen
semget (...)
sem_init (...)
sem_open (...)
initialisieren
semctl (...)
beim Erzeugen
beim Erzeugen
P (...)
semop (...)
sem_wait (...)
sem_wait (...)
V (...)
semop (...)
sem_post (...)
sem_post (...)
Objekt freigeben
semctl (...)
sem_destroy (...)
sem_close (...)
sem_unlink (...)
Operation
POSIX Threads
Objekt erzeugen
pthread_mutex_init (...)
initialisieren
-
P (...)
pthread_mutex_lock (...)
V (...)
pthread_mutex_unlock (...)
Objekt freigeben
pthread_mutex_destroy (...)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
usw.
Betriebssysteme
•
Folie 2 - 56
Skizze einer Implementierung (in C Notation):
#define NIL
#define MAX_SEMIDS
(struct queue *) NULL
32
typedef int semaphore;
struct { int
value;
struct queue *wait_ptr;
} sem_array[MAX_SEMIDS];
/* Zaehlervariable
/* Warteschlange der PCBs
*/
*/
int idx;
/* Index in "sem_array"
*/
semaphore init_sem (int value)
{
if (value >= 0)
{
/* freien Eintrag im Feld suchen
idx = ...;
sem_array[idx].value
= value;
sem_array[idx].wait_ptr = NIL;
}
else
{
fprintf (stderr, "....");
exit (-1);
}
return (semaphore) idx;
}
*/
/* noch wartet kein Prozess
void P (semaphore s)
{
if (sem_array[(int) s].value > 0)
{
sem_array[(int) s].value -= 1;
/* krit. Abschnitt frei
}
else
{
/* Prozess stoppen; Zustand auf "blockiert" setzen; Prozess in
* Warteliste des Semaphors s eintragen
*/
}
}
void V (semaphore s)
{
if (sem_array[(int) s].wait_ptr == NIL)
/* Warteschlange leer?
{
sem_array[(int) s].value += 1;
}
else
{
/* einen wartenden Prozess auswaehlen; Prozess in Zustand
* "rechenwillig" bringen, ...
*/
}
}
*/
*/
*/
(P-Operation: Wenn der Zähler der Semaphor-Variablen größer als Null ist, wird er dekrementiert und der Prozess darf den kritischen Bereich betreten. Andernfalls wird er in der
Warteschlange der Semaphor-Variablen blockiert.
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 57
V-Operation: Wenn die Warteschlange der Semaphor-Variablen leer ist, wird der Zähler
inkrementiert und damit das Betriebsmittel (der kritische Bereich) freigegeben, damit ein
Prozess später erfolgreich die P-Operation ausführen kann. Andernfalls wird ein Prozess
aus der Warteschlange „befreit“, der dann sofort den kritischen Abschnitt betreten bzw. das
Betriebsmittel benutzen darf. In diesem Fall wird der Zähler der Semaphor-Variablen nicht
inkrementiert, da der kritische Bereich bzw. das Betriebsmittel bereits wieder durch den
„befreiten“ Prozess belegt ist.
Die P-Operation „testet“ den Zähler der Semaphor-Variablen und die V-Operation deren
Warteschlange.)
•
Lösung des wechselseitigen Ausschlusses mit Hilfe eines Semaphors
semaphore s;
int main (void)
{
s = init_sem (1);
COBEGIN
p1 ();
p2 ();
COEND;
rel_allsem ();
}
/* ==========
Hauptprogramm
========= */
/* Semaphor erzeugen und initialisieren */
/* beide Prozesse starten
*/
void p1 (void)
{
for (;;)
{
sonstige Arbeit;
P (s);
kritischer Abschnitt;
V (s);
}
}
/* ============
Prozess 1
=========== */
void p2 (void)
{
for (;;)
{
sonstige Arbeit;
P (s);
kritischer Abschnitt;
V (s);
}
}
/* ============
Prozess 2
=========== */
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 58
Implementierung des Programms in C (semaphor.c)
#include
#include
#include
#include
#define
#define
#define
#define
#define
<stdio.h>
<stdlib.h>
<time.h>
"parallel.h"
NUM_THR
NUM_CYCLES
MAX_NTIME
MAX_CTIME
SEM_VAL
6
30
4
2
1
/*
/*
/*
/*
/*
# of concurrent threads
# of normal/critical cycles
max. time for normal work
max. time for critical work
initial semaphore value
*/
*/
*/
*/
*/
void worker (long id);
void prt_msg (char *name, long id, char *text, int cycle);
semaphore ex,
screen;
/* exclusive access
*/
/* synchronize output on screen*/
int main (void)
{
ThrID_t thr_id[NUM_THR];
int
i;
/* ID's of concurrent threads
/* loop variable
srand ((unsigned int) time ((time_t *) NULL));
screen = init_sem (SEM_VAL);
/* initialize semaphores
ex
= init_sem (SEM_VAL);
/* start concurrent threads
for (i = 0; i < NUM_THR; ++i)
{
thr_id[i] = parallel ((PtrFunc_t) worker, i);
}
/* wait until all concurrent threads have terminated
join_all (thr_id, NUM_THR);
rel_allsem ();
/* release semaphore
return EXIT_SUCCESS;
*/
*/
*/
*/
*/
*/
}
void worker (long id)
{
int i;
/* loop variable
*/
for (i = 0; i < NUM_CYCLES; ++i)
{
prt_msg ("Worker", id, "doing normal work in cycle", i);
/* simulate some normal work
*/
SLEEP ((unsigned int) rand () % MAX_NTIME);
prt_msg ("Worker", id, "try to enter critical section in cycle", i);
P (ex);
prt_msg ("Worker", id, "doing critical work in cycle", i);
/* simulate some critical work
*/
SLEEP ((unsigned int) rand () % MAX_CTIME);
V (ex);
}
}
void prt_msg (char *name, long id, char *text, int cycle)
{
P (screen);
printf ("%s %ld: %s %d.\n", name, id, text, cycle);
V (screen);
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 59
Implementierung des Programms in Java (ab Java 5)
Datei: SemaphorOneMain.java
import java.util.concurrent.Semaphore;
public class SemaphorOneMain
{
public static void main (String args[])
{
final int
NUM_THR = 6;
/* # of threads
final int
SEM_VAL = 1;
/* initial sem. value
final Semaphore ex
= new Semaphore (SEM_VAL, true);
*/
*/
WorkerOne thr[] = new WorkerOne[NUM_THR];
/* create all threads
for (int i = 0; i < NUM_THR; ++i)
{
thr[i] = new WorkerOne (i, ex);
thr[i].start ();
}
/* Join all terminating threads
for (int i = 0; i < NUM_THR; ++i)
{
try
{
String thrName = thr[i].getName ();
*/
*/
thr[i].join ();
System.out.println ("SemaphorOneMain: '" + thrName +
"' terminated.");
} catch (InterruptedException e)
{
System.err.println ("SemaphorOneMain: received unexpected " +
"InterruptedException while joining "+
"'" + thr[i].getName () + "'.");
}
}
}
}
Datei: WorkerOne.java
import java.util.concurrent.Semaphore;
class WorkerOne extends Thread
{
private int
thrID;
private final Semaphore ex;
private boolean
isNotInterrupted;
/* ID of this thread
/* interrupt received? */
public WorkerOne (int thrID, Semaphore ex)
{
this.thrID = thrID;
this.ex
= ex;
setName ("WorkerOne-" + Integer.toString (thrID));
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
Betriebssysteme
public void
{
final int
final int
final int
Folie 2 - 60
run ()
MAX_NTIME = 3000;
MAX_CTIME = 1000;
NUM_CYCLES = 30;
/* max. 3 s normal work
*/
/* max. 1 s crit. work
*/
/* # of normal/critical cycles */
String name = getName () + ": ";
isNotInterrupted = true;
for (int i = 0; (i < NUM_CYCLES) && isNotInterrupted; ++i)
{
System.out.println (name + "doing normal work in cycle " + i);
try
/* simulate it
{
Thread.sleep ((int) (Math.random () * MAX_NTIME));
} catch (InterruptedException e)
{
System.err.println (getName () + ": Received " +
"unexpected InterruptedException.");
isNotInterrupted = false;
/* terminate loop
}
if (isNotInterrupted)
{
System.out.println (name + "try to enter critical section " +
"in cycle " + i);
/* check if thread has been interrupted in acquire-operation
try
{
ex.acquire ();
} catch (InterruptedException e)
{
System.err.println ((Thread.currentThread ()).getName () +
": Interrupted while waiting for " +
"resources in acquire-operation.");
isNotInterrupted = false;
/* terminate loop
}
}
if (isNotInterrupted)
{
try
/* simulate critical work
{
System.out.println (name + "doing critical work in " +
"cycle " + i);
Thread.sleep ((int) (Math.random () * MAX_CTIME));
} catch (InterruptedException e)
{
System.err.println (getName () + ": Received " +
"unexpected InterruptedException.");
isNotInterrupted = false;
/* terminate loop
}
ex.release ();
}
}
}
public String toString ()
{
return getName ();
}
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
*/
*/
*/
*/
*/
Betriebssysteme
•
Folie 2 - 61
Programmänderungen bei Endlosschleife
Datei: SemaphorTwoMain.java
...
public class SemaphorTwoMain
{
...
/* wait some time before terminating all threads
try
{
Thread.sleep (WAIT_TIME);
} catch (InterruptedException e)
{
System.err.println ("SemaphorTwoMain: received unexpected " +
"InterruptedException.");
}
/* Terminate all threads.
for (int i = 0; i < NUM_THR; ++i)
{
System.out.println ("SemaphorTwoMain: I stop thread '" +
thr[i].getName () + "'.");
thr[i].stopThread ();
}
/* Join all terminating threads
...
}
Datei: WorkerTwo.java
...
class WorkerTwo extends Thread
{
...
public void run ()
{
...
isNotInterrupted = true;
for (int i = 0; isNotInterrupted; ++i)
{
...
}
}
public void stopThread ()
{
try
{
isNotInterrupted = false;
this.interrupt ();
} catch (SecurityException e)
{
System.err.println (getName () + ": Caught unexpected " +
"security exception.");
}
}
...
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
*/
*/
Betriebssysteme
Folie 2 - 62
•
neben dem wechselseitigen Ausschluss ist die Synchronisation von
Prozessen eine wichtige Aufgabe in der parallelen Programmierung
•
Beispiele
−
Erzeuger/Verbraucher-Problem (producer/consumer problem)
♦ ein Prozess erzeugt Daten und ein anderer verbraucht
(bearbeitet) die Daten
(z. B. Datenaustausch zwischen Gerätetreiber und Verarbeitungsprogramm)
♦ Kopplung der Prozesse über einen gemeinsamen Puffer
♦ Zugriff muss synchronisiert werden
⋅
Erzeuger darf nicht in vollen Puffer schreiben
⋅
Verbraucher darf nicht aus leerem Puffer lesen
♦ drei Varianten werden untersucht
⋅
Zwischenpuffer für ein Datenelement
⋅
unbeschränkt großer Zwischenpuffer
⋅
beschränkter Zwischenpuffer
♦ die verfügbaren Datenelemente bzw. freien Pufferplätze
sollen über allgemeine Semaphore bestimmt werden
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 63
Leser/Schreiber-Problem (readers/writers problem)
♦ beliebig viele Prozesse dürfen gleichzeitig Daten lesen
♦ zu jedem Zeitpunkt darf nur ein Prozess Daten modifizieren
(falls mehrere Prozesse gleichzeitig Daten schreiben, könnte es zu Dateninkonsistenzen kommen, z. B. bei Dateien, Datenbanken, ...)
♦ Lösung soll möglichst hohen Grad an Parallelarbeit erlauben, ohne die Exklusivität der Schreiber zu verletzen
♦ zwei Varianten können untersucht werden
1) Leser haben eine höhere Priorität als Schreiber
⋅
Zugriff auf Datenbanken/Dateien
(Online-Versandhauskataloge, Online-Wetterdienst, Kontoauszugsdrucker, ...)
⋅
gelegentlicher Änderungsdienst
2) Schreiber haben eine höhere Priorität als Leser
⋅
Abbuchungs-, Informations-, Reservierungssysteme
(Platzreservierung in der Bahn oder im Flugzeug, Geldausgabegeräte
bei Banken, ...)
⋅
umgehende Aktualisierung des Datenbestands erforderlich
(Platz kann nur einmal gebucht werden, Kontostand muss immer
aktuell sein, ...)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 64
Problem der speisenden Philosophen (dining philosophers problem)
−
Lösungsversuche liefern viele Erkenntnisse über Synchronisationsprobleme bei parallelen Abläufen
−
Verklemmungsmöglichkeiten (deadlock) werden untersucht
−
unbegrenzt langes Zurückstellen bei der Prozesssynchronisation
(starvation) wird untersucht und veranschaulicht
−
hat darüber hinaus keine praktische Bedeutung
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Lösung 1 des Erzeuger/Verbraucher-Problems
semaphore voll, leer;
int main (void)
{
leer = init_sem (1);
voll = init_sem (0);
COBEGIN
erzeuger ();
verbraucher ();
COEND;
rel_allsem ();
}
void erzeuger (void)
{
for (;;)
{
P (leer);
erzeuge;
V (voll);
}
}
void verbraucher (void)
{
for (;;)
{
P (voll);
verbrauche;
V (leer);
}
}
−
diskutieren Sie die Lösung
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Folie 2 - 65
Betriebssysteme
•
Folie 2 - 66
Lösung 3 des Erzeuger /Verbraucher-Problems
(Lösung 2 fehlt nicht, sondern wird im Rahmen der Diskussion der Lösung 1 erstellt)
−
beschränkte Puffergröße
−
Füllungsgrad des Puffers soll über Semaphore realisiert werden
#define PUFFERGROESSE
semaphore AnzSatz,
AnzFrei,
s;
4
/* Anzahl Saetze im Puffer
*/
/* Anzahl freie Plaetze im Puffer
*/
/* wechselseitiger Ausschluss auf Puffer */
int main (void)
{
AnzSatz = init_sem (0);
AnzFrei = init_sem (PUFFERGROESSE);
s
= init_sem (1);
COBEGIN
erzeuger ();
verbraucher ();
COEND;
rel_allsem ();
}
void erzeuger (void)
{
for (;;)
{
empfange Datensatz;
P (AnzFrei);
/* ggf. auf freien Platz warten
P (s);
/* Puffer reservieren
speichere Datensatz in Puffer;
V (s);
/* Puffer freigeben
V (AnzSatz);
/* Verbraucher informieren
}
}
void verbraucher (void)
{
for (;;)
{
P (AnzSatz);
/* ggf. auf Datensatz warten
P (s);
/* Puffer reservieren
hole Datensatz aus Puffer;
V (s);
/* Puffer freigeben
V (AnzFrei);
/* Erzeuger informieren
bearbeite Datensatz;
}
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
*/
*/
*/
*/
*/
*/
*/
Betriebssysteme
•
Folie 2 - 67
Lösung 1 des Leser/Schreiber-Problems: Leser haben höhere
Priorität als Schreiber
−
kein Leser darf zum Warten genötigt werden, wenn kein
Schreiber schreibt
−
kein Leser muss nur deshalb warten, weil ein Schreiber darauf
wartet, dass der letzte Leser fertig wird
−
Hinweise zum Programm
1) es wird ein Semaphor s für den wechselseitigen Ausschluss
der Schreiber benötigt
2) die Menge der Leser wird als Ganzes den Schreibern
gleichgestellt
3) eine globale Variable AnzLeser zählt die Anzahl der aktiven
Leser
4) der Zugriff auf die globale Variable AnzLeser wird durch das
Semaphor ex synchronisiert
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Programm
int
AnzLeser;
semaphore s, ex;
int main (void)
{
AnzLeser = 0;
s
= init_sem (1);
ex
= init_sem (1);
COBEGIN
leser (1);
...
leser (n);
schreiber (1);
...
schreiber (m);
COEND;
rel_allsem ();
}
void leser (long id)
{
P (ex);
AnzLeser = AnzLeser + 1;
if (AnzLeser == 1)
{
P (s);
}
V (ex);
Daten lesen;
P (ex);
AnzLeser = AnzLeser - 1;
if (AnzLeser == 0)
{
V (s);
}
V (ex);
Daten verarbeiten;
}
void schreiber (long id)
{
Daten erzeugen;
P (s);
Daten schreiben;
V (s);
}
−
diskutieren Sie die Lösung
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Folie 2 - 68
Betriebssysteme
•
Folie 2 - 69
Lösung 2 des Leser/Schreiber-Problems: Schreiber haben höhere
Priorität als Leser
−
Schreiber sollen absolute Priorität gegenüber Lesern haben
⇒ ein Schreiber soll so schnell wie möglich den kritischen Abschnitt betreten
⇒ er muss eine eventuell vorhandene Leserwarteschlange nicht
berücksichtigen
(eine Leserwarteschlange kann entstehen, wenn mehrere Schreiber auf den
Zugriff zum kritischen Abschnitt warten)
−
ein Schreiber muss auf das Ende der Leseaktionen warten, die er
bei seiner Anmeldung vorfindet
(wenn ein Schreiber schreiben will, dürfen sich neue Leser dem Leser-Pool nicht mehr
zugesellen)
−
Programm
int
AnzLeser, AnzSchreiber;
semaphore s, ex, LeserWS, LeserSperre, exs;
int main (void)
{
AnzLeser
= 0;
AnzSchreiber = 0;
s
= init_sem (1);
ex
= init_sem (1);
LeserWS
= init_sem (1);
LeserSperre = init_sem (1);
exs
= init_sem (1);
COBEGIN
leser (1);
...; leser (n);
schreiber (1); ...; schreiber (m);
COEND;
rel_allsem ();
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
void leser (long id)
{
P (LeserWS);
P (LeserSperre);
P (ex);
AnzLeser = AnzLeser + 1;
if (AnzLeser == 1)
{
P (s);
}
V (ex);
V (LeserSperre);
V (LeserWS);
Daten lesen;
P (ex);
AnzLeser = AnzLeser - 1;
if (AnzLeser == 0)
{
V (s);
}
V (ex);
Daten verarbeiten;
}
void schreiber (long id)
{
Daten erzeugen;
P (exs);
AnzSchreiber = AnzSchreiber + 1;
if (AnzSchreiber == 1)
{
P (LeserSperre);
}
V (exs);
P (s);
Daten schreiben;
V (s);
P (exs);
AnzSchreiber = AnzSchreiber - 1;
if (AnzSchreiber == 0)
{
V (LeserSperre);
}
V (exs);
}
−
diskutieren Sie die Lösung
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Folie 2 - 70
Betriebssysteme
Folie 2 - 71
Aufgabe 2-7:
Gegeben sei der folgende Pseudocode für das Erzeuger-/Verbraucherproblem:
int
n;
semaphore s, delay;
int main (void)
{
ThrID_t thr_id[2];
n
= 0;
s
= init_sem(1);
delay = init_sem(0);
thr_id[0] = parallel ((PtrFunc_t) erzeuger, 0);
thr_id[1] = parallel ((PtrFunc_t) verbraucher, 1);
...
}
void erzeuger (long id)
{
for (;;)
{
erzeuge Datensatz;
P (s);
lege Datensatz im Puffer ab;
n = n + 1;
if (n == 1)
{
V (delay);
}
V (s);
}
}
void verbraucher (long id)
{
int m;
P (delay);
for (;;)
{
P (s);
entnehme Datensatz aus Puffer;
n = n - 1;
m = n;
V (s);
verbrauche Datensatz;
if (m == 0)
{
P (delay);
}
}
}
Warum würde das Programm fehlerhaft arbeiten, wenn die Anweisung
„if (m == 0) ...“ in der Funktion verbraucher durch die Anweisung „if (n == 0) ...“ ersetzt wird? Welcher Fehler tritt auf?
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 72
Problem der speisenden Philosophen (Dijkstra, 1971)
Fünf Philosophen leben gemeinsam in einem Haus. Ihr Leben besteht abwechselnd aus Denken, Essen und Schlafen. Während die
Resultate ihres Denkens und ihre Schlafgewohnheiten ohne Bedeutung sind, entsteht beim Essen ein echtes Problem: Die Philosophen
nehmen ihre Mahlzeiten an einem gemeinsamen runden Tisch ein,
an dem jeder seinen festen Platz mit einem eigenen Teller hat. Es
wird stets ein schwierig zu essendes Spaghetti-Gericht serviert, das
nur mit zwei Gabeln verzehrt werden kann. Zwischen je zwei Tellern
liegt jedoch nur eine Gabel.
Gesucht wird ein Algorithmus, der ohne Vorschrift individueller
Essenszeiten die Gabelverteilung so regelt, dass kein Philosoph verhungern muss. Selbstverständlich ist vorausgesetzt, dass ein
essender Philosoph gelegentlich satt wird, seine Gabeln säubert und
sie zurücklegt.
0
4
0
4
1
3
3
1
2
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
2
Betriebssysteme
•
Folie 2 - 73
Lösung 1 des Philosophen-Problems
−
Ein hungriger Philosoph greift zuerst nach der rechten Gabel.
Hat er diese erhalten, so greift er nach der linken Gabel. Erhält er
diese ebenfalls, so darf er essen. In allen anderen Fällen muss er
warten.
−
diese Lösung ist nicht verklemmungsfrei
(Falls alle Philosophen gleichzeitig hungrig werden, und gleichzeitig ihre rechten Gabeln aufnehmen, erhält keiner seine linke Gabel, sodass alle Philosophen verhungern.)
−
Programm
#define N 5
semaphore Gabel[N];
int main (void)
{
int i;
for (i = 0; i < N; ++i)
{
Gabel[i] = init_sem (1);
/* alle Gabeln frei
}
COBEGIN
Philosoph (0); ...; Philosoph (N-1);
COEND;
rel_allsem ();
*/
}
void Philosoph (long id)
{
for (;;)
{
Philosoph denkt;
P (Gabel[id]);
P (Gabel[(id + 1) % N]);
Philosoph isst;
V (Gabel[id]);
V (Gabel[(id + 1) % N]);
}
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
/* rechte Gabel
/* linke Gabel
*/
*/
Betriebssysteme
−
Ausgabe des Programms phil_1
...
Philosopher 2: ttttttttttttttt try to get my forks
Philosopher 1: I'm thinking in cycle 12.
Philosopher 0: I'm eating
Philosopher 2: have my right fork
Philosopher 1: ttttttttttttttt try to get my forks
Philosopher 4: I'm eating
Philosopher 4: I'm thinking in cycle 13.
Philosopher 4: ttttttttttttttt try to get my forks
Philosopher 4: have my right fork
Philosopher 4: I'm eating
Philosopher 0: I'm thinking in cycle 13.
Philosopher 0: ttttttttttttttt try to get my forks
Philosopher 1: have my right fork
Philosopher 4: I'm thinking in cycle 14.
Philosopher 4: ttttttttttttttt try to get my forks
Philosopher 4: have my right fork
Philosopher 4: I'm eating
Philosopher 4: I'm thinking in cycle 15.
Philosopher 4: ttttttttttttttt try to get my forks
Philosopher 4: have my right fork
Philosopher 4: I'm eating
Philosopher 4: I'm thinking in cycle 16.
Philosopher 4: ttttttttttttttt try to get my forks
Philosopher 4: have my right fork
Philosopher 4: I'm eating
Philosopher 4: I'm thinking in cycle 17.
Philosopher 4: ttttttttttttttt try to get my forks
Philosopher 4: have my right fork
Philosopher 4: I'm eating
Philosopher 4: I'm thinking in cycle 18.
Philosopher 3: I'm eating
Philosopher 3: I'm thinking in cycle 7.
Philosopher 3: ttttttttttttttt try to get my forks
Philosopher 3: have my right fork
Philosopher 3: I'm eating
Philosopher 0: have my right fork
Philosopher 4: ttttttttttttttt try to get my forks
Philosopher 4: have my right fork
Philosopher 3: I'm thinking in cycle 8.
Philosopher 3: ttttttttttttttt try to get my forks
Philosopher 3: have my right fork
^C Signal SIGINT received. All semaphore id's will be released.
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Folie 2 - 74
Betriebssysteme
•
Folie 2 - 75
Lösung 1* des Philosophen-Problems
−
Erweiterung von Lösung 1: Falls ein Philosoph seine linke
Gabel nicht erhält, legt er seine rechte Gabel zurück
−
Diskussion der Lösung 1*
♦ schwierig, da Prozesssysteme im Allgemeinen nicht
reversibel sind
(z. B. automatische Blockade bei P-Operation)
♦ alle Philosophen könnten ihre rechten Gabeln im gleichen
Takt aufnehmen und zurücklegen
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 76
Lösung 2 des Philosophen-Problems
−
eine andere Erweiterung von Lösung 1: Der Zugriff auf die Gabeln wird exklusiv immer nur einem Philosophen gestattet
−
Programm
#define N 5
semaphore Gabel[N],
ex;
int main (void)
{
int i;
for (i = 0; i < N; ++i)
{
Gabel[i] = init_sem (1);
/* alle Gabeln frei
*/
}
ex = init_sem (1);
/* Gabelzugriff erlaubt*/
COBEGIN
Philosoph (0); ...; Philosoph (N-1);
COEND;
rel_allsem ();
}
void Philosoph (long id)
{
for (;;)
{
Philosoph denkt;
P (ex);
P (Gabel[id]);
P (Gabel[(id + 1) % N]);
V (ex);
Philosoph isst;
V (Gabel[id]);
V (Gabel[(id + 1) % N]);
}
}
−
diskutieren Sie die Lösung
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
/* exklusiver Zugriff
/* rechte Gabel
/* linke Gabel
*/
*/
*/
Betriebssysteme
•
Folie 2 - 77
Lösung 3 des Philosophen-Problems
−
Problem kann nicht mit Semaphor-Variablen allein gelöst werden
−
ein Philosoph muss feststellen, ob er die zweite Gabel bekommt,
bevor er die erste Gabel aufnimmt
⇒ Zustandsvariablen sind erforderlich, die gelesen werden
können
−
Philosoph i befindet sich zu jedem Zeitpunkt in genau einem der
folgenden Zustände
♦ c[i] = 0 Philosoph i denkt,
♦ c[i] = 1 Philosoph i ist hungrig,
♦ c[i] = 2 Philosoph i ist sehr hungrig,
♦ c[i] = 3 Philosoph i isst.
(Der Zustand c[i] == 2 wird erst in der vierten Lösungsvariante benötigt und stellt
sicher, dass Philosoph i nicht verhungert, indem er gegenüber seinen Nachbarn unter
gewissen Bedingungen eine höhere Priorität erhält.)
−
Semaphor-Variablen werden jetzt den Philosophen und nicht
mehr den Gabeln zugeordnet
−
ein hungriger Philosoph muss u. U. von seinen Nachbarn zum
Essen geschickt werden
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 78
Programm
#define N 5
int
c[N];
semaphore Phil[N],
ex;
int main (void)
{
int
i;
for (i = 0; i < N; ++i)
{
Phil[i] = init_sem (0);
/* Philosoph darf nicht essen */
c[i]
= 0;
/* Philosoph denkt
*/
}
ex = init_sem (1);
COBEGIN
Philosoph (0); ...; Philosoph (N-1);
COEND;
rel_allsem ();
}
/* ein Philosoph darf essen, wenn er hungrig ist und
* keiner seiner beiden Nachbarn isst
*/
void Test (long id)
{
if ((c[(id - 1 + N) % N] != 3) &&
(c[id] == 1)
&&
(c[(id + 1) % N] != 3))
{
c[id] = 3;
V (Phil[id]);
/* Essen erlauben
}
}
void Philosoph (long id)
{
for (;;)
{
Philosoph denkt;
P (ex);
c[id] = 1;
Test (id);
V (ex);
P (Phil[id]);
Philosoph isst;
P (ex);
c[id] = 0;
Test ((id - 1 + N) % N);
Test ((id + 1) % N);
V (ex);
}
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
/* Philosoph id ist hungrig
/* darf er essen ?
*/
*/
/* ggf. warten
*/
/* Philosoph id denkt
*/
Betriebssysteme
Folie 2 - 79
Diskussion der Lösung
•
exklusiver Zugriff auf die globalen Zustandsvariablen c[i]
•
wichtigster Teil des Programms ist die Prozedur Test
−
wird von jedem Philosophen zunächst in eigener Sache aufgerufen, wenn er hungrig ist (Test, ob einer seiner Nachbarn isst)
−
falls kein Nachbar isst, wird er durch die V (Phil[i])-Anweisung
der Prozedur Test zum Essen zugelassen
−
andernfalls muss er an seiner P (Phil[i])-Anweisung darauf
warten, dass er von seinen Nachbarn zum Essen geschickt wird,
sobald sie ihre Mahlzeit beendet haben
−
ein Ausdruck in der if-Anweisung der Prozedur Test ist immer
redundant
♦ c[i] == 1 ist redundant, wenn ein Philosoph die Funktion in
eigener Sache aufruft
(der Ausdruck wird erst benötigt, wenn ein Philosoph nach dem Essen für seine
Nachbarn die Prozedur Test aufruft, um sie ggf. zum Essen zu schicken)
♦ c[i + 1] != 3 oder c[i - 1] != 3 ist redundant, wenn ein
Philosoph die Funktion für einen Nachbarn aufruft
(er ruft die Prozedur erst auf, wenn er seine Mahlzeit beendet hat, sodass für ihn
c[i] == 0 gilt)
•
der Algorithmus ist verklemmungsfrei (Beweis: siehe Literatur)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 80
der Algorithmus garantiert nicht, dass jeder Prozess innerhalb einer
gewissen Zeit ablaufen kann
(durch eine bösartige Kooperation von Philosophen kann ein Philosoph verhungern)
−
wenn sich die beiden Nachbarn eines Philosophen mit dem
Essen abwechseln, verhungert er zwischen ihnen
(diese Kooperation kann allerdings gestört werden, sobald einer der beiden übrigen
Philosophen hungrig wird)
−
vier Philosophen können so geschickt kooperieren, dass der
fünfte Philosoph verhungert
(hier Philosoph 2; siehe z. B. F. Pieper: Einführung in die Programmierung paralleler
Prozesse, Oldenbourg, 1977)
−
lfd. Nr.
c[0]
c[1]
c[2]
c[3]
c[4]
1
2
3
4
5
6
7
8
9
10
11
12
13
1
1
1
3
3
3
0
0
0
0
1
1
1
3
3
0
0
0
1
1
3
3
3
3
3
3
1
1
1
1
1
1
1
1
1
1
1
1
1
1
3
3
3
3
3
3
3
0
0
0
1
1
0
0
0
0
1
1
1
1
1
3
3
3
0
Zeile 13 entspricht Zeile 1 ⇒ Zyklus kann unendlich oft
wiederholt werden
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 81
Lösung 4 des Philosophen-Problems (F. Hofmann, Erlangen, 1974)
#define N 5
int
c[N];
semaphore Phil[N],
ex;
int main (void)
{
...
}
void Test (long id)
{
if (((c[(id - 1 + N) % N] < 2) &&
(c[id] == 1)
&&
(c[(id + 1) % N] < 2))
||
(c[id] == 2))
{
c[id] = 3;
V (Phil[id]);
}
}
/* entspricht Loesung 3
*/
/* Essen erlauben
*/
void Erbarmen (long id)
{
if ((c[id] == 1)
&&
((c[(id - 1 + N) % N] == 3) ||
(c[(id + 1) % N] == 3)))
{
c[id] = 2;
}
}
void Philosoph (long id)
{
for (;;)
{
Philosoph denkt;
P (ex);
c[id] = 1;
/* Philosoph id ist hungrig
*/
Test (id);
/* darf er essen ?
*/
V (ex);
P (Phil[id]);
/* ggf. warten
*/
Philosoph isst;
P (ex);
c[id] = 0;
/* Philosoph id denkt
*/
/* Nachbarn ggf. zum Essen schicken
*/
Test ((id - 1 + N) % N);
Test ((id + 1) % N);
/* prüfen, ob Philosoph (id-1) bzw. (id+1) zwischen zwei essenden
* Philosophen sass, als er hungrig wurde
* ⇒ der Philosoph ist inzwischen sehr hungrig
*/
Erbarmen ((id - 1 + N) % N);
Erbarmen ((id + 1) % N);
V (ex);
}
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 82
Diskussion der Lösung
•
Philosophen können sich nicht gegen einen Kollegen verschwören
⇒ kein Philosoph muss verhungern
(wird durch den Zustand sehr hungrig sichergestellt, der dem Philosophen Priorität gibt.
Beweis: siehe z. B. F. Pieper: Einführung in die Programmierung paralleler Prozesse,
Oldenbourg, 1977)
•
ein Philosoph wird genau dann sehr hungrig, wenn er hungrig ist
und seine beiden Tischnachbarn gleichzeitig essen
(der Zustand wird eingestellt, wenn einer der Nachbarn seine Mahlzeit beendet)
•
kein Nachbar eines sehr hungrigen Philosophen wird zum Essen
zugelassen
•
Test überprüft, ob ein Nachbar des hungrigen Philosophen i isst oder
sehr hungrig ist
(Philosoph i wird zum Essen zugelassen, wenn dies nicht der Fall ist; c[i] == 2 kommt nur
vor, wenn beide Nachbarn weder essen noch selbst sehr hungrig sind; der eine Nachbar hat
den Zustand nach seiner Mahlzeit gesetzt (Prozedur Erbarmen) und der andere Nachbar hat
Philosoph i zum Essen geschickt (Prozedur Test))
•
in Erbarmen ist die Abfrage c[i + 1] == 3 oder c[i - 1] == 3
redundant, da der Zustand des aufrufenden Prozesses 0 ist
Aufgabe 2-8:
Die Philosophen 1, 3 und 2 werden in dieser Reihenfolge hungrig. Danach werden die Philosophen 1 und 3 satt. Beschreiben Sie den Ablauf.
Geben Sie die Werte der Felder Phil und c während des Ablaufs an.
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 83
Beurteilung des Lösungsansatzes „Semaphore“
1) nebenläufige Programme können unabhängig voneinander
entwickelt werden
2) beliebig viele Prozesse können relativ einfach synchronisiert werden
3) aktives Warten wird vermieden
4) nicht geeignet für verteilte Systeme (Rechnernetze), da ein Prozess
auf Rechner A keine Semaphor-Variable von Rechner B kennt und
auch nicht in eine Warteschlange einer Semaphor-Variablen auf
Rechner B eingekettet werden kann
5) wenn eine P-Operation erfolglos war, wird der Prozess gestoppt und
kann keine anderen Aktionen vorziehen
(es gibt entsprechende Erweiterungen des Konzepts, die das verhindern)
6) ein Prozess kann nicht auf ein beliebiges Semaphor aus einer Menge
warten, wenn er mehrere exklusive Betriebsmittel benötigt
(es gibt entsprechende Erweiterungen des Konzepts, die das erlauben)
7) fehleranfällig, da der Programmierer sehr leicht Fehler begehen kann
a) falls eine P-Operation aufgrund eines (bewussten oder
unbewussten) Programmierfehlers fehlt, ist der wechselseitige
Ausschluss nicht gewährleistet
b) wenn eine V-Operation vergessen wird, können einzelne Prozesse auf Dauer blockiert werden
c) wenn die Reihenfolge der P- bzw. V-Operationen falsch programmiert wird, kann es zu Verklemmungen kommen
(siehe Aufgabe beim Erzeuger/Verbraucher Problem)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 84
8) es gibt kein Rezept zur Lösung der Kooperationsprobleme, das zuverlässig zu einer richtigen Lösung führt
9) hat man eine Lösung gefunden, ist es im Allgemeinen noch
schwieriger, die Allgemeingültigkeit und Richtigkeit der Lösung
nachzuweisen
(siehe Philosophenproblem)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 85
2.4.3 Monitore
•
Semaphore sind leistungsfähige, aber unstrukturierte Mechanismen
zur Prozesskoordinierung
−
Semaphoroperationen können in der gesamten Anwendung
verstreut sein
−
globale Auswirkungen der Operationen sind deshalb schwer zu
überblicken
⇒ es werden Sprachmittel für strukturierte Koordinierung benötigt
⇒ Sprachmittel sollten in Programmiersprache eingebettet sein
(höhere Sicherheit, da die Benutzung der Sprachmittel vom Compiler überprüft wird
⇒ besser als die bisherigen Programmierkonventionen)
⇒ Semaphore können zur Realisierung der Sprachmittel benutzt
werden
•
ein Monitor ist ein solches strukturiertes Sprachmittel
(vorgeschlagen von Dijkstra (1971), Brinch Hansen (1972); formal definiert von Hoare
(1974); erweitert von Lampson und Redell (1980) für die Programmiersprache Mesa, ...)
−
besteht aus Prozeduren/Funktionen und Datenstrukturen
−
vergleichbar mit einer Klasse einer objektorientierten Programmiersprache
−
der Monitor stellt sicher, dass nur ein Prozess zu einem
Zeitpunkt seine Prozeduren/Funktionen benutzt
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 86
ein Monitor besteht aus den drei folgenden Teilen:
1) Deklarationsteil für private Daten
2) lokale und globale Prozeduren zur Manipulation dieser Daten
3) Initialisierungsprogramm für die Daten (Hauptprogramm des Monitors)
•
prinzipielle Syntax
monitor Name_des_Monitors
Deklaration der Variablen
private procedure i1 (...)
{
...
}
...
private procedure im (...)
{
...
}
public procedure p1 (...)
{
...
}
...
public procedure pn (...)
{
...
}
{
Initialisierung der Daten
}
•
Monitorkonzept wird z. B. in den Programmiersprachen Concurrent
Pascal, Modula-2, Modula-3, Mesa und Java unterstützt
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
•
Folie 2 - 87
Monitor benötigt Sprachmittel zur Synchronisation von Prozessen
innerhalb des Monitors
−
Prozess muss auf die Erfüllung einer Bedingung warten können
−
Prozess muss aktiviert werden, sobald die Bedingung erfüllt ist
Synchronisation innerhalb eines Monitors wird unterstützt durch
−
Bedingungsvariablen
♦ Typ: condition
♦ repräsentieren nur eine Prozess-Warteschlange
(sie entsprechen damit einer Semaphor-Variablen ohne Zählervariable)
−
Operation wait
wait (x) bzw. x.wait bewirkt, dass aufrufender Prozess blockiert
und in Warteschlange der Bedingungsvariablen x eingekettet
wird
(entspricht der P-Operation, wobei der Prozess aber in jedem Fall blockiert wird)
−
Operation signal oder notify
♦ signal (x), x.signal, notify (x) bzw. x.notify bewirkt, dass ein
auf die Bedingung x wartender Prozess aktiviert wird
(entspricht der V-Operation, wobei eine signal-Operation ohne Wirkung bleibt,
wenn die Warteschlange der Bedingungsvariablen leer ist, d. h., dass ein Prozess,
der später eine wait-Operation ausführt, warten muss, bis erneut eine signalOperation ausgeführt wird)
♦ bei signal wird der aufgeweckte Prozess sofort aktiviert und
der signalisierende Prozess wird blockiert, während er bei
notify erst dann aktiviert wird, wenn der signalisierende Prozess den Monitor verlassen hat oder wait aufgerufen hat
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 88
Aufruf der wait-Operation gibt Monitor für andere Prozesse frei
(notwendig, da der Prozess den Monitor sonst blockieren würde, weil sich nur ein Prozess
im Monitor befinden darf)
•
beim Aufruf der signal-Operation gibt es ein Problem
1. der Prozess, der die signal-Operation ausführt, befindet sich im
Monitor
2. der Prozess, der u. U. durch die signal-Operation geweckt wird,
befindet sich ebenfalls im Monitor
⇒ zwei Prozesse wären im Monitor, obwohl zu jedem Zeitpunkt
nur ein Prozess im Monitor aktiv sein darf !!!
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 89
Lösung: einer der beiden Prozesse muss warten
1) der Prozess, der die signal-Operation ausführt, muss warten
(Vorschlag von Hoare)
−
der signalisierende Prozess wird in einer Prioritätswarteschlange blockiert
−
sobald der aufgeweckte Prozess den Monitor verlässt oder
sich selbst durch eine neue wait-Operation deaktiviert, wird
ein Prozess aus der Prioritätswarteschlange gestartet
2) signal-Operation darf nur als letzte Anweisung einer Monitorprozedur ausgeführt werden
(d. h., dass der aktive Prozess den Monitor sofort verlässt und damit nur der aufgeweckte Prozess im Monitor aktiv ist; diese Variante wird z. B. in Concurrent Pascal
benutzt)
queue of
entering
processes
Monitor
entrance
waiting area
signal (c1)
wait (c1)
condition c1
...
signal (cn)
wait (cn)
condition cn
local data
procedure 1
...
procedure k
wait, exit
signal
priority queue
initialization code
exit
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 90
3) der aufgeweckte Prozess muss warten
(Vorschlag von Lampson und Redell für die Sprache Mesa)
−
ein aufgeweckter Prozess wird aktiviert, sobald der
signalisierende Prozess den Monitor verlässt oder sich selbst
durch eine wait-Operation deaktiviert
−
die Funktion signal wird hier im Allgemeinen notify genannt
−
aufgeweckte Prozesse warten in einer Warteschlange innerhalb des Monitors oder gemeinsam mit neuen Prozessen in
der Eingangswarteschlange des Monitors
(abhängig von der Implementierung; in der Sprache Java warten aufgeweckte
Prozesse gemeinsam mit neuen Prozessen in der Eingangswarteschlange und
haben damit keine Priorität gegenüber neuen Prozessen)
queue of
entering or
notified
processes
*
Monitor
entrance
waiting area
*
wait, exit
local data
queue of notified processes
notify (c1)
wait (c1)
condition c1
...
*
procedure 1
...
procedure k
notify (cn)
wait (cn)
condition cn
*
initialization code
exit
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 91
„Problem“ bei Lösung 3
−
es ist nicht sichergestellt, dass ein Prozess ablaufen kann, dem
eine Bedingung als wahr gemeldet worden ist
−
Beispiel
P1:
...
if (Bedingung_1 falsch)
{
wait (B1);
}
...
P2:
...
if (Bedingung_2 falsch)
{
wait (B2);
}
...
♦ beide Prozesse warten
♦ Prozess im Monitor informiert beide Prozesse mit notify (B1)
und notify (B2), dass ihre Bedingungen wahr geworden sind
♦ sobald der Prozess den Monitor verlässt, kann einer der beiden Prozesse (z. B. P1) den Monitor wieder betreten
♦ da P1 alle Variablen im Monitor ändern darf, kann es
vorkommen, dass Bedingung B2 wieder falsch wird
♦ wenn P2 den Monitor wieder betritt, kann er nicht davon
ausgehen, dass die Bedingung B2 noch wahr ist
⇒ jeder Prozess muss die Bedingung noch einmal überprüfen,
d. h. die Anweisung if (...) muss durch while (...) ersetzt
werden
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Lösung 3 erlaubt zeitlich begrenztes Warten
−
problemlose Erweiterung, da jeder Prozess seine Bedingung
noch einmal überprüft
−
Erweiterung der Operationen
−
•
Folie 2 - 92
wait (Bedingung)
⇒
wait (Bedingung, max_zeit)
notify (Bedingung)
⇒
keine Änderung
robuster gegenüber Programmierfehlern (keine dauerhafte Blockierung)
Erweiterung des Konzepts durch Prioritätswarteschlangen
−
Prozesse sollen mit unterschiedlicher Priorität auf Wiedereintritt
in Monitor warten
−
Erweiterung der Operationen
wait (Bedingung)
⇒
wait (Bedingung, Priorität)
signal (Bedingung)
⇒
−
keine Änderung im Aufruf
−
aktiviert den Prozess mit der
höchsten Priorität
•
beim Start eines „Monitorprogramms“ werden die Initialisierungsprogramme der Monitore vor dem eigentlichen Programm ausgeführt
•
Monitorprozeduren sind bis zum Aufruf durch einen Prozess passiv
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 93
Beispiel
−
Lösung des Erzeuger/Verbraucherproblems mit Hilfe eines
Monitors
−
Programm besteht aus dem Monitor Puffer, den beiden Prozessen Erzeuger und Verbraucher sowie dem Hauptprogramm
#define PUFFERGROESSE
4
monitor Puffer
<Puffertyp> puf[PufferGroesse];
int
sIdx, lIdx,
AnzSatz;
condition
nichtleer, nichtvoll;
/* Schreib-/Leseindex
/* Anzahl Datensaetze
*/
*/
public procedure ablegen (Datensatz)
{
if (AnzSatz == PufferGroesse)
{
wait (nichtvoll);
}
puf[sIdx] = Datensatz;
sIdx = (sIdx + 1) % PufferGroesse;
AnzSatz++;
signal (nichtleer);
}
public procedure entnehmen (Datensatz)
{
if (AnzSatz == 0)
{
wait (nichtleer);
}
Datensatz = puf[lIdx];
lIdx = (lIdx + 1) % PufferGroesse;
AnzSatz--;
signal (nichtvoll);
}
{
/* Monitor-Hauptprogramm
sIdx
= 0;
lIdx
= 0;
AnzSatz = 0;
}
int main (void)
{
COBEGIN
Erzeuger (1); ...; Erzeuger (n);
Verbraucher (1); ...; Verbraucher (m);
COEND;
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
Betriebssysteme
Folie 2 - 94
void Erzeuger (long i)
{
for (;;)
{
empfange Datensatz;
Puffer.ablegen (Datensatz);
}
}
void Verbraucher (long i)
{
for (;;)
{
Puffer.entnehmen (Datensatz);
bearbeite Datensatz;
}
}
•
Implementierung des Monitors Puffer in Java
−
die Schlüsselwörter monitor und condition gibt es nicht
−
die Funktion signal heißt notify bzw. notifyAll
−
wait, notify und notifyAll sind parameterlos
(Java unterstützt auch zeitlich begrenztes Warten ⇒ wait hat Parameter)
−
Monitor wird als Klasse realisiert
−
Monitor-Hauptprogramm ist der Konstruktor der Klasse
−
exklusive Benutzung der Monitorprozeduren wird über das
Schlüsselwort synchronized erreicht
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 95
Java-Programm für einen Puffer für ganze Zahlen
class IntBuffer
{
final
int
BUF_SIZE = 5;
/* buffer size
private int
buffer[] = new int[BUF_SIZE];
private int
readIndex, writeIndex; /* read / write index
private boolean cellAvail,
/* free cells are available
dataAvail;
/* data is available
*/
*/
*/
*/
public IntBuffer ()
{
readIndex = 0;
writeIndex = 0;
cellAvail = true;
dataAvail = false;
}
public synchronized void putVal (int val) throws InterruptedException
{
while (!cellAvail)
{
try
{
wait ();
/* wait for free cells
*/
} catch (InterruptedException e)
{ ...
}
}
buffer[writeIndex] = val;
writeIndex
= (writeIndex + 1) % BUF_SIZE;
dataAvail
= true;
if (writeIndex == readIndex)
{
cellAvail = false;
}
notifyAll ();
/* signal data available
*/
}
public synchronized int getVal () throws InterruptedException
{
int val;
while (!dataAvail)
{
try
{
wait ();
/* wait for data
} catch (InterruptedException e)
{ ...
}
}
val
= buffer[readIndex];
readIndex = (readIndex + 1) % BUF_SIZE;
cellAvail = true;
if (readIndex == writeIndex)
{
dataAvail = false;
}
notifyAll ();
/* signal free cells
return val;
}
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
*/
Betriebssysteme
•
Folie 2 - 96
prinzipielle Implementierung von Monitoren über Semaphore
(für Lösung 1 des signal-Problems)
−
folgendes muss sichergestellt werden:
♦ höchstens ein Prozess darf eine Monitorprozedur ausführen
⇒ wechselseitiger Ausschluss für Monitorprozeduren
♦ eine wait-Operation muss den Prozess bei der entsprechenden Bedingung blockieren
♦ signal-Operation darf an beliebiger Stelle ausgeführt werden
⇒ aktueller Prozess wird ggf. sofort blockiert und erhält
höchste Priorität zum Wiederbetreten des Monitors
♦ falls ein Prozess den Monitor freigibt, wird der nächste
Prozess in folgender Reihenfolge bestimmt
♦ zuerst wird überprüft, ob Prozesse bei einer signalOperation blockiert wurden
♦ danach wird überprüft, ob ein neuer Prozess den Monitor
betreten will
⇒ Prozesse, die auf Bedingung warten, bleiben blockiert
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 97
für jeden Monitor werden die folgenden Variablen benötigt
(u. U. in der Form: <Monitorname>_<Variablenname>)
ex
binäres Semaphor; Anfangsinitialisierung: 1;
überwacht die exklusive Benutzung der Monitorprozeduren
prio
binäres Semaphor; Anfangsinitialisierung: 0;
für Prozesse, die eine signal-Operation ausführen
und blockiert werden müssen
prio_cnt
Zähler; Anfangsinitialisierung: 0;
gibt die Anzahl der in prio blockierten Prozesse an
cond[i]
Feld von binären Semaphoren; Anfangsinitialisierung: 0; für Prozesse, die auf Bedingungen warten
(Feld muss so groß gewählt werden, dass für jede Bedingungsvariable ein Element vorhanden ist)
cond_cnt[i]
Feld von Zählern; Anfangsinitialisierung: 0;
geben die Anzahl der in cond[i] blockierten Prozesse an
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 98
1) jede Monitorprozedur wird in folgenden Code eingeschlossen
P (ex);
/* max. 1 Prozess im Monitor
*/
/* Wiedereintritt nach signal
*/
Monitorprozedur;
if (prio_cnt > 0)
{
V (prio);
}
else
{
V (ex);
}
/* neuem Proz. Zutritt erlauben */
2) für jeden Monitorbefehl wait (xyz) wird folgender Code erzeugt
cond_cnt[xyz]++;
if (prio_cnt > 0)
{
V (prio);
}
else
{
V (ex);
}
P (cond[xyz]);
cond_cnt[xyz]--;
/* Wiedereintritt nach signal
*/
/* neuem Proz. Zutritt erlauben */
/* Prozess blockieren
*/
3) für jeden Monitorbefehl signal (xyz) wird dieser Code erzeugt
if (cond_cnt[xyz] > 0)
{
prio_cnt++;
V (cond[xyz]);
/* wartenden Prozess aktivieren
P (prio);
/* aktuellen Prozess blockieren
prio_cnt--;
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
*/
*/
Betriebssysteme
•
Folie 2 - 99
Implementierung ist einfacher, wenn signal-Operation nur als letzte
Anweisung einer Monitorprozedur vorkommen darf
(Lösung 2 des signal-Problems)
Monitorprozedur
⇒
P (ex);
Monitorprozedur;
wait (xyz)
⇒
cond_cnt[xyz]++;
V (ex);
P (cond[xyz]);
cond_cnt[xyz]--;
signal (xyz)
⇒
if (cond_cnt[xyz] > 0)
{
V (cond[xyz]);
}
else
{
V (ex);
}
Warum steht die V (ex)-Anweisung nicht nach der Monitorprozedur
sondern im else-Teil von signal ( )?
•
Monitore sind genauso mächtig wie Semaphore, d. h., Semaphore
können durch Monitore implementiert werden
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 100
Simulation von Semaphoren durch Monitore in Java
class Semaphore
{
private int value;
public Semaphore (int value)
{
if (value < 0)
{
this.value = 0;
System.err.println ("Semaphore value must be positive. " +
"Value changed to 0.");
}
else
{
this.value = value;
}
}
public synchronized void P () throws InterruptedException
{
while (value == 0)
{
try
{
wait ();
} catch (InterruptedException e)
{
String msg = (Thread.currentThread ()).getName () +
": Interrupted while waiting for resources in P-operation.";
throw new InterruptedException (msg);
}
}
value--;
}
public synchronized void V ()
{
value++;
notify ();
}
}
−
keine exakte Simulation der Semaphoroperationen
−
Befreiung eines wartenden Prozesses erfolgt durch MonitorMechanismus
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 101
genauere Simulation der Semaphoroperationen in Java
class ErrSemaphore
{
private int value;
private int waitCnt;
/* value of semaphore
/* number of threads in queue
*/
*/
public ErrSemaphore (int value)
{
if (value < 0)
{
this.value = 0;
System.err.println ("Semaphore value must be positive. " +
"Value changed to 0.");
}
else
{
this.value = value;
}
this.waitCnt = 0;
}
public synchronized void P () throws InterruptedException
{
if (value > 0)
{
value--;
}
else
{
while (value == 0)
{
waitCnt++;
try
{
wait ();
} catch (InterruptedException e)
{
String msg = (Thread.currentThread ()).getName () +
": Interrupted while waiting for resources in P-operation.";
throw new InterruptedException (msg);
}
waitCnt--;
}
}
}
public synchronized void V ()
{
if (waitCnt > 0)
{
notify ();
}
else
{
value++;
}
}
}
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
−
Folie 2 - 102
Verklemmung, wenn ein Prozess im kritischen Bereich ist und
mindestens ein Prozess in der P-Operation wartet
(Der Prozess im kritischen Bereich sendet notify und reiht sich dann bei seiner nächsten P-Operation in die Warteschlange der anderen Prozesse ein. Der geweckte
Prozess muss die Bedingung erneut evaluieren. Da der Wert der Semaphor-Variablen
immer noch Null ist, reiht er sich ebenfalls in die Liste der wartenden Prozesse ein ⇒
in Java kann eine genauere Simulation der Semaphoroperation nicht so einfach
realisiert werden.)
−
Demonstration des Fehlers
...
Worker2-2: try to enter critical section in cycle 0
P: semaphore value: 1 -> thread can pass
Worker2-2: doing critical work in cycle 0
Worker2-3: try to enter critical section in cycle 0
P: Worker2-3 will be queued; waiting threads: 1
Worker2-0: try to enter critical section in cycle 0
P: Worker2-0 will be queued; waiting threads: 2
V: semaphore value: 0
waiting threads: 2
V: notify () performed
P: Worker2-3 thread has dequeued; waiting threads: 1
P: Worker2-3 will be queued; waiting threads: 2 (wegen erneuter Evaluation)
Worker2-2: doing normal work in cycle 1
Worker2-5: try to enter critical section in cycle 0
P: Worker2-5 will be queued; waiting threads: 3
Worker2-4: try to enter critical section in cycle 0
P: Worker2-4 will be queued; waiting threads: 4
Worker2-1: try to enter critical section in cycle 0
P: Worker2-1 will be queued; waiting threads: 5
Worker2-2: try to enter critical section in cycle 1
P: Worker2-2 will be queued; waiting threads: 6
<Verklemmung>
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 103
Beurteilung des Lösungsansatzes „Monitor“
1) Monitore sind genauso mächtig wie Semaphore
2) Monitore erzwingen eine klare Programmstruktur
3) der Zugriff auf gemeinsame Betriebsmittel ist nur in der vorgesehenen Weise über Monitorprozeduren möglich
4) die Koordinierung der Prozesse ist Aufgabe des Programmierers
•
er entscheidet, welche Prozesse blockiert werden
•
er realisiert die Deblockierung
5) Lösungen mit Monitoren sind wesentlich weniger fehleranfällig als
solche mit Semaphoren
6) Monitore können einfach und effizient implementiert werden
7) geschachtelte Monitoraufrufe können zu einer nicht beabsichtigten
Sequenzialisierung der Programme führen (⇒ u. U. ineffizient)
8) nicht in Rechnernetzen verwendbar, da das Monitorkonzept auf
lokalen Daten und lokalen Prozeduren beruht
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 104
Aufgabe 2-9:
a) Warum gibt es bei der Lösung des wechselseitigen Ausschlusses
durch globale Variablen Probleme?
b) Drei Prozesse benutzen gemeinsame Daten zum Datenaustausch.
Zeigen Sie, dass die Realisierung des wechselseitigen Ausschlusses
u. U. nicht fair ist, wenn nur ein Semaphor verwendet wird. Eine
Realisierung heißt fair, wenn garantiert ist, dass ein Prozess nach
endlicher Zeit fortfahren kann.
Aufgabe 2-10:
Gegeben sei die folgende Simulation für ein binäres Semaphor.
monitor BinarySemaphore
int
sem_val;
condition ws;
public procedure P (void)
{
if (sem_val > 0)
{
sem_val--;
}
else
{
wait (ws);
}
}
public procedure V (void)
{
if (sem_val == 0)
{
sem_val++;
}
else
{
signal (ws);
}
}
{
sem_val = 1;
}
a) Zeigen Sie, dass das obige Programm keine korrekte Simulation für
ein binäres Semaphor ist.
b) Führen Sie alle notwendigen Änderungen im obigen Programm
durch, sodass es ein binäres Semaphor korrekt simuliert.
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 105
2.5 Prozesskommunikation
•
Austausch von Informationen zwischen kooperierenden Prozessen
(Interprozesskommunikation, interprocess communications, IPC)
•
Kommunikationsmöglichkeiten
−
Shared Memory (gemeinsame Speicherbereiche)
−
Pipes (Kommunikationskanäle, FIFO-Dateien)
−
Nachrichtenübertragung
−
Mailbox-System (Nachrichtenwarteschlange)
−
Sockets
−
Remote Procedure Call (RPC, entfernter Prozeduraufruf)
−
usw.
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 106
2.5.1 Shared Memory
•
effizienter Datenaustausch zwischen parallelen Prozessen
(im Allgemeinen schnellste Möglichkeit der Datenübertragung zwischen zwei Prozessen)
•
Prozesse müssen Datenkonsistenz selbst sicherstellen
(Synchronisation der Zugriffe z. B. über Semaphore)
•
Realisierung direkt im Hauptspeicher (z. B. UNIX System V IPC)
oder über memory-mapped files (z. B. UNIX, Microsoft Windows)
•
Funktionen
System V IPC UNIX mmap
Win32/Win64-API
Speicherbereich anlegen
shmget ()
open ()
lseek ()
write ()
CreateFileMapping ()
OpenFileMapping ()
Speicherbereich anbinden
shmat ()
mmap ()
MapViewOfFile ()
Speicherbereich freigeben
shmdt ()
munmap ()
UnmapViewOfFile ()
Speicherbereich löschen
shmctl ()
close ()
unlink ()
CloseHandle ()
DeleteFile ()
(bei UNIX mmap wird die Größe einer neuen Datei dadurch festgelegt, dass mit lseek ( ) eine Position in der
Datei festgelegt wird, an der dann mit write ( ) ein Zeichen geschrieben wird)
•
Konzept von memory-mapped files
virtual memory
of process 1
file view 1
file view 2
physical memory
file on disk
virtual memory
of process 2
file mapping
object
file view 2
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 107
−
über mehrere mmap-/MapViewOfFile-Aufrufe können verschiedene Teile der Datei an verschiedene Stellen im virtuellen Speicher des Prozesses eingebunden werden
−
Pseudocode für direkten Dateizugriff
fd = open (...);
lseek (fd, offset, SEEK_SET);
read (fd, buf, len);
bearbeite Daten in „buf“
−
Pseudocode für Dateizugriff über mmap ( )
struct xyz {...} *buf;
fd = open (...);
buf = (struct xyz *) mmap (..., len, ..., fd, offset);
bearbeite Daten in Struktur „buf“
2.5.2 Pipes
•
unidirektionaler Datenfluss zwischen zwei Prozessen
•
keine Synchronisationsprobleme
•
unnamed Pipes zur Interprozesskommunikation zwischen verwandten Prozessen (Vater - Sohn, Sohn - Sohn, ...)
(realisiert als Puffer im Speicherbereich des Betriebssystemkerns)
•
named Pipes zur Interprozesskommunikation zwischen beliebigen
Prozessen
(realisiert als FIFO-Dateien im Dateisystem)
•
unnamed und named Pipes für einige Anwendungen zu langsam
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 108
•
Zugriff auf jede Pipe erfolgt über Datei-Deskriptoren
•
Realisierung einer „bidirektionalen Pipe“ durch zwei „unidirektionale Pipes“
parent process
child process
fd1[1]
fd2[0]
fd2[1]
fd1[0]
pipe 1
data flow
pipe 2
data flow
operating system kernel
•
Realisierung von „cat xyz | sort | more“
process cat
process sort
fd[1]
fd[1]
fd[0]
process more
fd[0]
pipe
pipe
data flow
data flow
operating system kernel
•
unnamed und named Pipes gibt es in UNIX und Microsoft Windows
(Win32/Win64-API)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 109
2.5.3 Nachrichtenübertragung
•
viele Dinge müssen festgelegt werden, bevor die Nachricht
übertragen werden kann
•
Anzahl der kommunizierenden Prozesse
sending
process
S
receiving
process
sending
process
R
receiving
processes
receiving
processes
S
R1
...
unicast
broadcast
Rn
P
sending
process
S
multicast
R1
...
Rn
Q
−
direkte Nachrichtenübermittlung
♦ 1 : 1 Beziehung zwischen Sender und Empfänger
♦ 1 : n Beziehung zwischen Sender und Empfängern
−
indirekte Nachrichtenübermittlung, z. B. über Puffer
(m : n Beziehung möglich)
•
Art der Adressierung
−
direkte Adressierung
(der Sender gibt eine Zieladresse an; der Empfänger gibt eine Quelladresse an oder
empfängt von allen Prozessen Nachrichten)
−
indirekte Adressierung
(die Nachricht wird nicht an einen speziellen Prozess sondern an eine Nachrichtenwarteschlange geschickt; Empfänger lesen aus der Nachrichtenwarteschlange)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 110
Synchronisation der Nachrichtenübertragung
−
sendender Prozess wird blockiert bis Nachricht empfangen
wurde oder wird nicht blockiert
−
empfangender Prozess kann sofort weiterlaufen, wenn Nachricht
im Puffer vorhanden
−
falls keine Nachricht im Puffer ist, wird der empfangende
Prozess blockiert oder nicht blockiert
−
synchroner Nachrichtenaustausch
(blockierendes Senden/Empfangen; ein synchroner Nachrichtenaustausch mit „leerer
Nachricht“ kann zur Synchronisation von Prozessen in Rechnernetzen benutzt werden;
wird manchmal auch Rendezvous genannt)
−
asynchroner Nachrichtenaustausch
(nicht blockierendes Senden/Empfangen; maximale Parallelarbeit)
−
Mischform: nicht blockierendes Senden und blockierendes
Empfangen
(wird häufig benutzt; Sender arbeitet mit maximaler Geschwindigkeit; Sender kann
Nachrichten an mehrere Empfänger schicken; Empfänger kann im Allgemeinen nur
dann sinnvoll weiterarbeiten, wenn er die Nachricht empfangen hat)
−
blockierendes Senden/Empfangen kann einen Prozess beliebig
lange blockieren
(z. B. bei Synchronisationsfehlern (beide Prozesse wollen senden oder empfangen),
bei Verlust von Nachrichten oder wenn ein Prozess fehlerhaft endet und keine
weiteren Nachrichten sendet/empfängt)
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 111
Format der Nachricht
−
hängt im Allgemeinen davon ab, ob das Nachrichtensystem nur
auf einem Rechner (z. B. UNIX System V message queues) oder
in einem Rechnernetz (z. B. Message-Passing Interface) zur
Verfügung steht
−
feste Nachrichtengröße: häufig Nachrichtenkopf plus Verweis
auf Nachricht
−
variable Nachrichtengröße: im Allgemeinen Nachrichtenkopf
inkl. Nachricht
message type
destination ID
source ID
message header
message length
control information
message contents
or pointer to
message contents
message body
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 112
Datenformate (ganze Zahlen, Gleitkommazahlen, Zeichencodierung, ...)
higher memory
lower memory
address
address
byte 0 byte 1 byte 2 byte 3 big-endian
byte 3 byte 2 byte 1 byte 0 little-endian
−
big-endian: Motorala 680x0, Sun Sparc, SGI Mips, ...
(Programm Endian.c im Programmarchiv zum Betriebssystempraktikum)
−
little-endian: Intel 80x86, ...
−
Gleitkommazahlen: Anzahl Bits für Mantisse und Exponent im
Allgemeinen unterschiedlich bei heterogenen Systemen
(Programm Floatingpoint.c im Programmarchiv zum Betriebssystempraktikum)
−
Zeichencodierung: ASCII, Unicode, ...
−
u. U. unterschiedliche Anordnung der Daten im Speicher
(alignment; z. B. müssen manche Datentypen auf geraden oder durch 4, 8 oder 16
teilbaren Adressen beginnen, damit ein (schneller) Datenzugriff möglich ist; abhängig
von der CPU; manchmal auch abhängig vom Compiler)
(Programm StructTwo.c im Programmarchiv zum Betriebssystempraktikum)
−
in heterogenen Rechnernetzen müssen alle Datenformate
zwischen plattformabhängiger und plattformunabhängiger
Darstellung transformiert werden
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 113
Übertragung einer Nachricht
−
send (Adresse, Nachricht)
−
receive (Adresse, Nachricht)
sending
process
receiving
process
messagepassing
module
messagepassing
module
process ID message
−
Beispiel für eine Client/Server-Anwendung
client 1
PID = 87
type = 1
type = 87
client 2
PID = 65
type = 1
type = 65
client 3
PID = 93
type = 1
type = 93
message queue
type = 1
type = 65, 87, or 93
server
♦ Nachrichtenauswahl über Nachrichtentyp
♦ fester Typ für Server, unterschiedliche Typen für Clients
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 114
2.5.4 Mailbox-System
•
indirekte Adressierung
•
asynchrone Nachrichtenübertragung
•
Betriebssystemfunktionen zum Anlegen/Entfernen einer Mailbox/
Nachrichtenwarteschlange
•
Betriebssystemfunktionen zum Senden/Empfangen einer Nachricht
•
Mailbox/Nachrichtenwarteschlange mit m : n Beziehung
sending
processes
receiving
processes
R1
S1
...
mailbox
Sm
•
...
Rn
Mailbox/Nachrichtenwarteschlange mit m : 1 Beziehung
(in diesem Fall wird die Mailbox oft Port genannt)
sending
processes
receiving
process
S1
...
port
R1
Sm
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 115
Funktionen in Microsoft Windows (Win32/Win64-API)
Mailbox anlegen
CreateMailslot ()
Mailbox öffnen
CreateFile ()
Nachricht senden
WriteFile ()
Nachricht empfangen
ReadFile ()
Mailbox schließen
CloseHandle ()
−
der Server (Empfänger) legt eine Mailbox an
−
die Clients öffnen die Mailbox zum Schreiben
−
die Mailbox wird automatisch zerstört, wenn der letzte Prozess
seine Mailbox schließt
−
ein Prozess kann sowohl Server als auch Client sein, sodass eine
bidirektionale Kommunikation möglich ist
−
mehrere Prozesse können aus einer Mailbox lesen, wenn sie den
entsprechenden Deskriptor kennen
(z. B. Sohnprozesse eines Mailbox-Servers)
•
Funktionen für Nachrichtenwarteschlangen in UNIX
POSIX message queues
System V message queues
mq_open ()
mq_close ()
mq_unlink ()
mq_send ()
mq_receive ()
msgget ()
msgctl ()
msgsnd ()
msgrcv ()
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 116
2.5.5 Sockets
•
Endpunkte für Kommunikationsverbindungen
•
jedem Socket ist genau ein Prozess zugeordnet
•
für (heterogene) Rechnernetze geeignet
•
weit verbreitet (z. B. unter UNIX, Microsoft Windows, Java verfügbar)
•
Socket-Systemaufrufe in C bei verbindungsorientiertem Protokoll
(TCP/IP)
create a socket
Server
Client
socket ()
socket ()
bind a well-known port number to
the socket
bind ()
establish a queue for connections
listen ()
accept a connection
read from connection
accept ()
recv ()
recvfrom ()
recvmsg ()
...
establish a
connection
data
transfer
connect ()
send ()
sendto ()
sendmsg ()
...
write to connection
send ()
sendto ()
sendmsg ()
recv ()
recvfrom ()
recvmsg ()
close a connection
close ()
close ()
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 117
Sockets in Java mit verbindungsorientiertem Protokoll (TCP/IP)
Server
Client
ServerSocket ()
accept ()
InputStream ()
...
establish a
connection
data
transfer
Socket ()
OutputStream ()
...
OutputStream ()
InputStream ()
close ()
close ()
−
vereinfachte Programmierung gegenüber C
−
ServerSocket ( ) führt automatisch die Funktionen socket ( ),
bind ( ) und listen ( ) aus
−
Socket ( ) führt automatisch die Funktionen socket ( ) und
connect ( ) aus
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
Folie 2 - 118
2.5.6 Remote Procedure Call
•
bidirektionaler Nachrichtenaustausch
•
für (heterogene) Rechnernetze geeignet
•
Prozess erhält Dienstleistung eines entfernten Prozesses über
„gewöhnlichen“ Prozeduraufruf
⇒ wesentlich weniger fehleranfällig, da alle Sende- und
Empfangsoperationen und alle Datenkonvertierungen
automatisch erzeugt werden
⇒ Netzwerk und Kommunikationsmechanismen sind transparent
für das Anwendungsprogramm
client
process
call
remote
server process
call
return
local
procedures
return
return
call
call
client stub
procedures
server stub
procedures
RPC
mechanism
RPC
mechanism
messagepassing
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
return
local
procedures
Betriebssysteme
•
Folie 2 - 119
Ablauf für synchronen, entfernten Prozeduraufruf
client
network
stub
stub
procedure
call
server
creates
message
RPC
waiting
analyses
message
procedure
call
waiting
return
RPC return
return
•
analyses
message
executes
local
procedure
creates
return
message
waiting
RPC-Schnittstelle wird in spezieller Sprache beschrieben
(Interface Definition Language, IDL, Microsoft Interface Definition Language, MIDL, RPC
Language, RPCL)
•
spezieller Compiler erzeugt aus der IDL-Beschreibung u. a. die
Platzhalter-Prozeduren (stubs), die lokale Prozeduraufrufe in RPCProzeduraufrufe überführen
(Unix: rpcgen, Microsoft Windows: MIDL Compiler)
•
IDL-Beschreibungen verschiedener Systeme sind im Allgemeinen
nicht kompatibel
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 120
Entwicklung eines RPC-Programms
−
RPC-Schnittstelle erstellen
−
Server implementieren, der Dienstleistungen erbringt
−
Client entwickeln, der die Dienstleistungen nutzt
develop the interface of remote procedures
RPCtest.idl
rpcgen
RPCtest_clnt.c
RPCtest.h
RPCtest_svc.c
client stub
procedure
server stub
procedure
RPCtest_client.c
RPCtest_server.c
develop the client
develop the server
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß
Betriebssysteme
•
Folie 2 - 121
RPCtest.idl für den RPC-Protokoll Compiler rpcgen
program RPCtest
{
version RPCtestVers2
{
string RetString (void)
= 1;
long
RetSquare (long)
= 2;
void
ShutDownServer (void) = 3;
} = 2;
version RPCtestVers1
{
string RetString (void) = 1;
} = 1;
} = 0x20000000;
const LatestRPCtestVers = 2;
−
der Server kann verschiedene Programmversionen unterstützen
−
Prozeduren werden fortlaufend nummeriert
−
Prozeduren mit gleichem Namen müssen in verschiedenen
Programmversionen dieselbe Nummer haben
−
über die Programm-, Versions- und Prozedurnummer werden
RPC-Prozeduren eindeutig identifiziert
−
Programme können mit eindeutiger Programmnummer offiziell
registriert werden oder eine beliebige Nummer aus dem Bereich
0x20 000 000 - 0x3f fff fff verwenden
−
rpcgen erzeugt aus der IDL-Datei die beiden Platzhalterdateien
und eine Header-Datei
Hochschule Fulda, Fachbereich AI, Prof. Dr. S. Groß