Processes and Threads

Prozesse and Threads
WS 09/10
IAIK
1
Prozesse
ƒ Programm in Ausführung
ƒ Mit einem Prozess verbunden:
ƒ Adressraum
ƒ Folge von Speicherstellen auf die der
Prozess zugreifen kann
ƒ Enthält ausführbares Programm, Daten
und Stack
ƒ Register (PC, SP und andere)
IAIK
2
Unterschied
Prozess : Programm
ƒ Prozess ist eine Aktivität
ƒ Besteht aus
ƒ Programm
ƒ Input
ƒ Output
ƒ Zustand
IAIK
3
Prozess-Tabelle
ƒ Annahme: mehrere Programme / Prozesse
ƒ Einen Stoppen, anderen Starten
ƒ Erster Prozess muss wieder gestartet werden
können – in genau demselben Zustand den er
beim Stoppen hatte
ƒ Information muss daher gesichert werden
ƒ ÆProzesstabelle
ƒ Unterbrochener Prozess: Core-Image plus
Prozesstabelle
IAIK
4
Prozess-Erzeugung
ƒ OS muss sicherstellen, dass alle
wichtigen Prozesse existieren.
ƒ Manchmal: alle Prozesse die
jemals benötigt werden beim
Startup erzeugt
ƒ Im allgemeinen: Möglichkeit zur
Erzeugung / Beendigung
erforderlich
IAIK
5
Prozesserzeugung
Wichtigste Ereignisse, die ProzessErzeugung veranlassen
1. System-Initialisierung (boot)
2. Ausführung eines process
creation system calls
3. Benutzeranforderung
4. Start eines Batch-Jobs
IAIK
6
Booten
ƒ Mehrere Prozesse werden gestartet
ƒ Prozesse zur Interaktion mit
Anwender
ƒ Prozesse für bestimmte Funktionen
ƒ
ƒ
ƒ
IAIK
Email-service
Drucker-Warteschlange
Firewall
7
Systemprozesse
IAIK
8
Prozesserzeugung
ƒ Auch später….
ƒ Technisch: Immer ein systemcall
ƒ Unix: fork (dann zwei idente Prozesse, bis
exec)
ƒ Windows: CreateProcess
ƒ SWEB: existiert – noch – nicht!
ƒ Beide Prozesse separaten Adressraum
ƒ Bei Unix: vorerst exakte Kopie
ƒ Bei Windows: von Beginn getrennt
IAIK
9
Prozess Terminierung
Bedingungen:
1. Normal exit(freiwillig)
2. Error exit (freiwillig)
Æ System call!
3. Fatal error (unfreiwillig)
4. Killed by another process
(unfreiwillig)
IAIK
10
Process Hierarchies
ƒ Parent erzeugt einen child process,
ƒ die können wieder Prozesse erzeugen
ƒ die können wieder Prozesse erzeugen
ƒ
…
ƒ Bildet Hierarchie
ƒ UNIX nennt das "process group"
ƒ Windows kennt keine Hierarchie
ƒ Alle Prozesse sind gleich
IAIK
11
Process Hierarchies
ƒ A forkt B,C
A
ƒ B forkt D,E,F
ƒ C forkt G
B
ƒ D forkt H
D
C
E
F
G
H
IAIK
12
Prozesszustände
Grep muster *.c | sort
Sort muss eventuell auf input
warten
Blockieren sinnvoll
IAIK
13
Zustand eines Prozesses
READY
TO
RUN
ReadyToRun
Yield
RUNNING
Run
Finish
resources free
JUST
CREATED
Forknew
IAIK
Sleep
ReadyToRun
event occurs
BLOCKED
needs to wait
for an event –
save user regs. PC
Stack pointer ...
process
14
Threads
ƒ Traditionelles Modell: Prozess hat
ƒ einen Adressraum
ƒ einen Ausführungsfaden
ƒ Manchmal wünschenswert,
mehrere „Ausführungsfäden“
parallel zu haben
ƒ wie eigene Prozesse, aber
gemeinsamer Adressraum
IAIK
15
Thread Model
ƒ Prozess bündelt
zusammengehörige Ressourcen.
ƒ Ressourcen:
ƒ Adressraum
ƒ Offene Files
ƒ Child Processes
ƒ Accounting
ƒ …
IAIK
16
Thread Model
ƒ Prozess besitzt Ausführungsfaden
(thread)
ƒ Threads: werden für die
Ausführung auf CPU verwaltet
ƒ Threads besitzen:
ƒ Befehlszähler (PC)
ƒ Register
ƒ Stack
IAIK
17
Thread Model
ƒ Erlaubt es, mehrere Fäden
innerhalb eines Prozesses laufen
zu lassen
ƒ Hohe Unabhängigkeit
ƒ Leichtgewichtige Prozesse
(lightweight processes)
ƒ Multithreading
IAIK
18
Thread Model
IAIK
19
Threads
ƒ Weniger unabhängig als Prozesse
ƒ Zugriff auf Speicher der anderen
Threads!
ƒ Kein Schutz voreinander!
ƒ Sollen kooperieren, nicht kämpfen!
IAIK
20
Thread-Zustände
ƒ Wie bei Prozessen
ƒ Ready
ƒ Running
ƒ Blocked
ƒ Terminiert
IAIK
21
Stacks
Jeder thread hat seinen Stack.
IAIK
22
Multithreading
ƒ Üblich: zuerst nur ein Thread
ƒ Startet weitere threads (z.B.
thread_create(procedure_name))
ƒ Manchmal hierarchisch, manchmal flach
ƒ Wenn thread fertig: thread_exit
ƒ Warten auf thread-Ende: thread_wait
ƒ CPU freiwillig hergeben: thread_yield
IAIK
23
Probleme
ƒ Entstehen gegebenenfalls durch
die gemeinsamen Datenbereiche
ƒ Thread schließt File, von dem ein
anderer noch liest?
ƒ Synchronisation!
IAIK
24
Probleme
ƒ Fork-Problem
ƒ Prozess habe >1 thread
ƒ Ein Thread eines Prozesses macht fork
ƒ Neuer Prozess: auch mehrere threads?
ƒ Wenn ja:
ƒ Ein thread ist blockiert und wartet auf I/O –
was macht dieser thread im neuen Prozess?
ƒ Design-Entscheidungen!
IAIK
25
Warum überhaupt threads
ƒ Oft sollen Dinge parallel ablaufen
ƒ Manche der „Dinge“ blockieren
ƒ Threads erzeugen einfacheres
Programmiermodell
ƒ Eigentlich dasselbe Argument wie für
Prozesse
ƒ Aber: threads haben Daten gemeinsam
ƒ Ermöglicht Lösungen, die mit Prozessen
nicht möglich oder nicht einfach wären
IAIK
26
Warum überhaupt threads
ƒ Weniger Ressourcen: einfacher zu
Erzeugen und Zerstören
ƒ Faktor 100
ƒ Wechsel zwischen Threads eines
Prozesses schneller als zwischen
Prozessen
ƒ Performancegewinn möglich
ƒ Nicht wenn alle CPU-lastig
ƒ Mehrprozessormaschinen
IAIK
27
Beispiele
ƒ Textverarbeitung
ƒ Benutzereingabe
ƒ Bildschirmanzeige
ƒ Formattierung
ƒ Rechtschreibprüfung
ƒ Autosave
ƒ Keine Chance mit
mehreren
Prozessen!
IAIK
28
Beispiele
ƒ Webserver
ƒ Sammlung von
sequentiellen
threads
ƒ Alle sehr einfach
IAIK
29
Beispiele
IAIK
30
Alternative: Ein Thread
ƒ Muss File von Platte lesen
ƒ Prozess wird blockiert
ƒ Schlechtere Performance
ƒ Non-blocking read
ƒ Mögliche Alternative
IAIK
31
Non-blocking read
(Sehr schematische Darstellung!)
while (TRUE) {
get_next_event(&buf);
if (is_request_event) {
if (page_not_in_cache) {
request_page_from_disk;
save_request_in_table;
} else return_page;
} else { //disk-event
find_request_in_table;
return_page;
}
}
IAIK
32
Non-blocking read
ƒ Kein sequentieller Prozess mehr
ƒ Prozess wird finite-state-machine!
ƒ Eigentlich werden threads
simuliert!
ƒ Daher: threads!
IAIK
33
Implementierung
ƒ Zwei Möglichkeiten:
ƒ Im User-Space
ƒ Im Kernel
ƒ (eventuell auch Hybrid)
IAIK
34
User-Space threads
ƒ Kernel weiss nichts von Threads
ƒ Für Kernel nur ein Prozess
ƒ Kann in allen BS realisiert werden,
auch wenn sie keinen threadsupport haben.
ƒ Früher waren das alle…
IAIK
35
Implementing Threads in User Space
IAIK
36
User-Space threads
ƒ Thread table pro Prozess
ƒ Analog zur Prozess-tabelle im
Kernel
ƒ Von runtime-system verwaltet
ƒ Wenn thread funktion ausführt, die
den Prozess blockieren könnte –
Aufruf einer Routine im runtimesystem
IAIK
37
User-Space threads
ƒ Routine prüft: thread blockieren?
ƒ Ja: Sichern der Register in Thread-
Table, thread im Zustand ready
suchen, Register mit dessen Werten
laden.
SP und PC wechseln – neuer thread
ist aktiv
ƒ Thread-switch auf diese Art: sehr
schnell!
IAIK
38
User-Space threads
ƒ Vorteile:
ƒ Kein Systemcall nötig
ƒ Daher sehr schnell
ƒ Kein context-switch, memory-cache flush
unnötig etc.
ƒ Eigenes Scheduling verwendbar
ƒ Nachteile
ƒ Thread darf keine System-Calls
machen – könnte blockiert werden
IAIK
39
Lösungen
ƒ Alle system-calls non-blocking
ƒ Änderungen am BS nicht attraktiv
ƒ Soll ja mit bestehenden BS arbeiten…
ƒ Auch Auswirkungen auf Userprogramme
ƒ Manchmal feststellbar ob Call blockiert
ƒ Select-Systemcall
ƒ Vor read: select (in library-routine)
ƒ Wenn read blockieren würde: anderen
thread wählen, und dann später wieder
„nachschauen“
ƒ Ineffizient und wenig elegant.
IAIK
40
Weitere Probleme
ƒ Page-fault
ƒ Kommen an sich später dran
ƒ Nicht das gesamte Programm im Speicher
ƒ Wenn nicht geladene Speicheradresse
referenziert wird: page fault
ƒ BS holt fehlendes von Platte
ƒ Prozess: blockiert! (nicht nur thread!)
ƒ Wenn Thread CPU nicht „hergibt“…
ƒ Keine Chance gegen „Bösewichte“!
IAIK
41
Kernel-Mode threads
ƒ Kein runtime-system mehr
ƒ Thread-Table im Kernel
ƒ Infos wie vorher
ƒ Tabelle Teil des Prozesstabelleneintrags
ƒ Thread-Erzeugung etc. system-call
ƒ Hauptnachteil: Aufwand für Systemcalls
viel höher als vorher
ƒ Thread-recycling
IAIK
42
Kernel-mode threads
IAIK
43
Hybride Implementierungen
IAIK
44
Reentrant libraries
ƒ Oft library-procedures auch nicht
reentrant oder „thread-safe“:
nicht für mehrfache, quasigleichzeitige Verwendung
entworfen
IAIK
48
Signals
ƒ Manche thread-spezifisch, andere nicht
ƒ Z.B. thread ruft alarm auf – signal soll
zu diesem thread gehen
ƒ Im User-mode: kernel kann das nicht
ƒ Mehrere threads verwenden alarm aber
nur ein alarm pro Prozess erlaubt. Was
tun?
ƒ Signal für Tastatur-Interrupt: wer soll
das Signal emfangen? Was, wenn ein
Thread den Signal-Handler
umkonfiguriert?
IAIK
49
Stacks
ƒ Mechanismen, die Stack
automatisch wachsen lassen
ƒ N threads – n stacks nötig
ƒ Wenn kernel die nicht kennt, kann
er nicht „helfen“
ƒ Probleme nicht unlösbar – aber
aufwändig….
IAIK
50