38
Prof. Dr. Peter Mandl Seite 1 CPU-Scheduling - Fallbeispiele Sommersemester 2015 Prof. Dr. Peter Mandl

CPU-Scheduling - Fallbeispiele · statischen Priorität zwischen -20 und +19 (wie unter Unix) -Priorität 0 bis 99 sind Echtzeitprioritäten Höhere Priorität mehr CPU-Zeit (höheres

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

Prof. Dr. Peter Mandl Seite 1

CPU-Scheduling - Fallbeispiele

Sommersemester 2015

Prof. Dr. Peter Mandl

Prof. Dr. Peter Mandl Seite 2

Gesamtüberblick

10

Job A

Job B

16 20 30

Job C

Job D

Job E

22 Verweilzeit

Alle Aufträge

beginnen hier

6

Job A

Job B

14 24 30

Job C

Job D

Job E

28 Verweilzeit

Alle Aufträge

beginnen hier

1. Einführung in Computersysteme

2. Entwicklung von Betriebssystemen

3. Architekturansätze

4. Interruptverarbeitung in Betriebssystemen

5. Prozesse und Threads

6. CPU-Scheduling

7. Synchronisation und Kommunikation

8. Speicherverwaltung

9. Geräte- und Dateiverwaltung

10.Betriebssystemvirtualisierung

Prof. Dr. Peter Mandl Seite 3

Überblick

1. Fallbeispiel: Unix

2. Fallbeispiel: Linux

3. Fallbeispiel: Windows

4. Fallbeispiel: Scheduling in Java

Prof. Dr. Peter Mandl Seite 4

Scheduling-Strategien unter Unix

Jedes Unix-Derivat hat Feinheiten in der Scheduling-Strategie

Es gibt aber prinzipielle Gemeinsamkeiten

Unterstützte Scheduling-Strategie:

- Preemptives Verfahren (Linux auch non-preemptive)

- Prozess als Scheduling-Einheit in traditionellem Unix

- RR mit Prioritäten und Multi-Level-Feedback-Scheduling

• Eine Queue je Priorität

• Round Robin innerhalb der gleichen Priorität

• Vorderster Prozess aus aktuell höchster Priority-Queue wird als nächstes ausgewählt

• Nach Ablauf der Zeitscheibe wird der Prozess ans Ende seiner aktuellen Queue oder ans Ende einer anderen Queue gehängt

Prof. Dr. Peter Mandl Seite 5

Run-Queue unter Unix

Multi-Level-Feedback-Warteschlangen organisiert in der sog. Run-Queue

Run queue

PCB-Tabelle

Verkettete PCB-Liste für jede Priorität 255

...

178

177

...

129

128

127

...

0

... Realtime

System

User

Prio

...

...

PCB 1

PCB 2

PCB 3

PCB 4

PCB 5

PCB 6

...

Prof. Dr. Peter Mandl

Scheduling unter Unix: Prioritätsberechnung

Jeder Prozess erhält eine initiale Priorität beim Start, die sich mit der Zeit verbessert

Priorität in früheren Unix-Systemen: -127 (höchste) bis +127

Priorität in heutigen Unix-Systemen: z.B. von 0 (höchste) bis 255

Die Priorität wird zyklisch, z.B. jede Sekunde, neu berechnet (System V)

Als Parameter geht die CPU-Nutzung der Vergangenheit in die Berechnung ein

- War diese in der letzten Zeit hoch, wird die Priorität niedriger

- I/O-intensive Prozesse (Dialogprozesse) werden bevorzugt

Seite 6

Prof. Dr. Peter Mandl Seite 7

Einschub: nice-Befehl unter Unix

nice-Befehl beeinflusst die statische Priorität beim Starten eines Programms: Nett zu anderen Prozessen sein, da die eigene Priorität meist

herabgesetzt wird

Nice-Prioritätenskala: von 20 bis -19 (höchste) Je größer der nice-Wert, desto niedriger die Priorität

Nutzung: nice -<nicewert> <command> - Programm <command> wird mit einer um <nicewert> niedrigeren

Priorität als der Standardwert gestartet

Vorsicht: Syntax je nach Shell etwas anders!

Test: nice -10 bash

Nur der User mit root-Berechtogung darf die Priorität erhöhen

Andere Befehle/Systemcalls - renice: Dient zum Verändern der Priorität eines laufenden Prozesses

- setpriority: Neuer Befehl anstelle von nice

Prof. Dr. Peter Mandl Seite 8

Überblick

1. Fallbeispiel: Unix

2. Fallbeispiel: Linux

3. Fallbeispiel: Windows

4. Fallbeispiel: Scheduling in Java

Prof. Dr. Peter Mandl Seite 9

Scheduling-Strategien unter Linux: O(1)-Scheduler (bis Kernel-Version 2.6.22)

RR mit Prioritäten und Multi-Level-Feedback-Mechanismus

Scheduling-Einheit ist der Thread (Implementierung auf Kernelebene) Thread und Prozess sind identisch!

Unterstützte Scheduling-Strategien: „ps -c“ zeigt Strategien der Threads/Prozesse an!

- Realtime FIFO (POSIX) SCHED_FIFO

• Höchste Priorität und non-preemptive (!)

- Realtime Round Robin (POSIX) SCHED_RR

• Wie FIFO aber preemptive, Nutzung einer Zeitscheibe

- Timesharing

• Standard-Threads

• SCHED_BATCH, SCHED_OTHER und SCHED_IDLE

Anm: Keine echten Realtime-Threads, sondern P.1003.4-Konformität (Unix real-time extension)

Prof. Dr. Peter Mandl Seite 10

O(1)-Scheduler: Run-Queue unter Linux (1)

Multi-Level-Feedback-Warteschlangen werden auch unter Linux über eine „Run-Queue“ verwaltet

Run-Queue

PCB 1

PCB-Tabelle

PCB 2

PCB 3

PCB 4

PCB 5

PCB 6

...

...

...

...

...

Prio

Verkettete PCB-Liste für jede

Priorität

0

...

99

100

...

...139

Realtime

Timesharing

Hinweis zum O(1)-Scheduler: Bezeichnung deshalb,

weil die Laufzeit für die Auswahl des nächsten Prozesses unabhängig von aktueller Prozessanzahl ist

Prof. Dr. Peter Mandl Seite 11

O(1)-Scheduler: Run-Queue unter Linux (2)

Prozess 200

Detailinformationen zu den

Prozessen/Threads in

task_struct-Datenstrukturen

(PCBs)

Prozess 232

...

...

Bitmap

Verkettete Prozess-Liste für

jede Priorität

0...

99

100...

139

Realtime-

Prio-Liste

Timesharing-

Prio-Liste

Active-Queuenr_active

Prozess 434

Prozess 699...

...

BitmapPrio

0...

99

100...

139

Expired-Queuenr_active

nr_running

Active-Zeiger

Expired-Zeiger

Current-Zeiger

Run-QueueIdle-Zeiger

dito wie Active-Queue

Idle-Prozess

...

...

... ...

Struktur prio_array

Struktur runqueue

Active Queue und expired Queue

Prof. Dr. Peter Mandl Seite 12

O(1)-Scheduler: Loadbalancer unter Linux

Je Prozessor gibt es eine Run-Queue

Loadbalancer verteilt die Arbeit

Loadbalancer

Prozess

Prozess

active

Prozess

Prozess

expired

Run-Queue CPU 1

CPU 1

Prozess

Prozess

active

Prozess

expired

Run-Queue CPU 2

CPU 2

.... Prozess

Prozess

active expired

Run-Queue CPU n

CPU n

Prof. Dr. Peter Mandl Seite 13

O(1)-Scheduler: Arbeitsweise des Linux-Schedulers

Die CPU wird einem Thread entzogen, wenn

- die Zeitscheibe (Quantum) abgelaufen ist

- der Thread blockiert (Warten auf Ressource)

- ein Thread mit höherer Priorität wird „ready“

• D.h.: Zwischendurch muss dies geprüft werden

• nach jedem Tick bei der Systemclock-Interrupt-Bearbeitung!

Die Quanten der Prozesse der höchsten Priorität werden soweit möglich abgearbeitet (außer wenn Prozess blockiert ist), danach wird die nächst niedrige Prioritäts-Queue bearbeitet

- Echtzeitprozesse können die anderen behindern

Prof. Dr. Peter Mandl Seite 14

Einschub: Skizze einer Timer-Interrupt-Routine

timer_interrupt() // Interrupt Service Routine für Systemuhr

{

Systemuhr anpassen;

Statistiken in Kerneldatenstrukturen aktualisieren;

Quantumszähler aktiver Prozesse reduzieren;

if (Prozess mit höherer Priorität im Zustand „ready“) {

schedule(); // Dispatcher aufrufen

}

else if (Quantum des laufenden Threads == 0) {

schedule(); // Dispatcher aufrufen

}

}

Prof. Dr. Peter Mandl Seite 15

Linux-Prioritäten

Jedem Thread wird eine statische und eine dynamische (effektive) Priorität zugeordnet

- Prioritätenskala intern: 0 bis 139

- Timesharing-Prioritäten liegen im Bereich von 100 bis 139 (100 ist höchste)

• Standardwert = 120

• nice-/setpriority-Systemdienst ermöglicht eine Veränderung der statischen Priorität zwischen -20 und +19 (wie unter Unix)

- Priorität 0 bis 99 sind Echtzeitprioritäten

Höhere Priorität mehr CPU-Zeit (höheres Quantum)

für den Prozess

Veränderung der effektiven Priorität führt zum Einhängen des Prozesses in andere Queue

Prof. Dr. Peter Mandl

O(1)-Scheduler: Quantumsberechnung unter Linux

Timesharing: Quantumsberechnung auf Basis der statischen Priorität in [ms]

quantum = f(static_prio) = (140 – static_prio) * 20, falls static_prio < 120

quantum = f(static_prio) = (140 – static_prio) * 5, falls static_prio >= 120

Beispiel: f(100) = (140 - 100) * 20 = 800 [ms]

100

800

120 139 Statische Priorität

(static_prio)

Quantum

in ms

100 105 110 115 125 130

700

500

400

300

200

600Höchste

Prio.

Die Quantumsberechnung z.B. in Timer-Interrupt-Routine

Seite 16

Prof. Dr. Peter Mandl

O(1)-Scheduler: Bonuszuteilung unter Linux

Bonus für Priorität in Abhängigkeit der durchschnittlichen Schlafzeit

- Negativer Bonus Verbesserung der Priorität

- Prio-Veränderung Einordnen in andere Queue

Effektive Priorität ~ (Statische Priorität + Bonus)

5

0

-5

500 1000 Durchschn.

Schlafzeit in [ms]

Bonus I/O-intensiver Prozess Guter

Bonus

Seite 17

Prof. Dr. Peter Mandl Seite 18

O(1)-Scheduler: Zusammenfassung

Statische Prioritäten bestimmen die CPU-Zuteilung und die Quantumszuteilung

Die effektive Priorität bestimmt die Einordnung in der Run-Queue

Rechenintensive Threads verbrauchen ihr Quantum schnell und erhalten dann ein Quantum abhängig von ihrer statischen Priorität und einen positiven Bonus (schlecht!) auf die effektive Priorität

also beeinflusst die statische Priorität das Quantum und die Rechenintensität die Priorität

Durchschnittliche Schlafzeit beeinflusst die Entscheidung, ob ein Prozess interaktiv (I/O-intensiv) oder rechenintensiv ist

I/O-intensive Threads erhalten einen negativen (gut!) Bonus auf die effektive Priorität und werden damit früher zugeteilt

Bonuszuteilung für müde Prozesse höhere Priorität

Prof. Dr. Peter Mandl Seite 19

Completely Fair Scheduler CFS: Überblick

Löst O(1)-Scheduler ab Linux-Version 2.6.23 ab

Scheduler für Timesharing-Prozesse

Modul fair.c, ca. 4.400 SLOC, implementiert CFS

Modul rt.c: nur noch ca. 1700 SLOC, implementiert nur noch Realtime-Scheduling mit nur noch 100 Prioritäten

Besonderheiten:

Keine Statistiken, keine Run Queue und kein Switching von active nach expired Queue

keine Quanten (Zeitscheiben)

Hinweis: CFS ist umstritten, da evtl. Nachteile für Workstations, aber Vorteile für Server

Prof. Dr. Peter Mandl

Completely Fair Scheduler CFS: Strategie

Einfache Strategie:

- Für jeden Prozess/Thread wird ein vruntime-Wert (Nanosekunden-Basis) verwaltet

- vruntime enthält die Entfernung von der idealen CPU-Nutzung

- Beispiel: 5 Prozesse 20 % CPU je Prozess

- Prozess mit niedrigster vruntime wird als nächstes gewählt und bleibt so lange aktiv, bis wieder ein fairer Zustand erreicht wurde

- Ziel: Wert von vruntime für alle Prozesse gleich halten

Hinweis:

- Linux-Kommando chrt -p <pid> liefert Scheduling-Policy und Priorität eines Prozesses und man kann mit chrt auch die Scheduling-Policy eines Prozesses setzen

Seite 20

Prof. Dr. Peter Mandl Seite 21

Überblick

1. Fallbeispiel: Unix

2. Fallbeispiel: Linux

3. Fallbeispiel: Windows

4. Fallbeispiel: Scheduling in Java

Prof. Dr. Peter Mandl

Scheduling-Strategien unter Windows

Windows verwendet ein

- prioritätsgesteuertes,

- preemptives Scheduling

- mit Multi-Level-Feedback

Threads dienen als Scheduling-Einheit

Seite 22

Prof. Dr. Peter Mandl

Prioritäten unter Windows: Kernelprioritäten

Threads werden nach Prioritäten in Multi-Level-Feedback-Warteschlangen organisiert

Interne Kernelprioritäten 0 (niedrigste) bis 31

- Nullseiten- und Idle-Thread haben die Priorität 0 (siehe Speicherverwaltung)

- Prioritäten 16 – 31 (Echtzeit) verändern sich nicht

- Prioritäten 1 – 15 sind dynamisch (Benutzerprozesse)

16

Echtzeitebenen

31

15

15 variable

Ebenen

16

1

0 1 Systemebene

Seite 23

Prof. Dr. Peter Mandl Seite 24

Run-Queue unter Windows

Multi-Level-Feedback-Warteschlangen

Ready-Queue für

Prozessor 1

...

...

...

Prio

Verkettete TCB-Listen für jede Priorität31...

16

15...

1

0

Realtime und

Systemprioritäten

Variable Prioritäten,

Userpriorität

System

Deferred Ready Queue

10000000……….00000010

Ready Summary (Bit-Map)

031 Threads im Zustand

Deferred Ready für jeden

Prozessor

...

...

Ready-Queue für

Prozessor 2

...

...

...

Deferred Ready Queue

00000000……….0000001

Ready Summary

031

31...

16

15...

1

0

Deferred Ready: Threads, die schon einem Prozessor zugeordnet sind, aber noch nicht aktiv sind

Prof. Dr. Peter Mandl Seite 25

Prioritäten unter Windows: WinAPI-Prioritäten

Es gibt 6 WinAPI-Prioritätsklassen der Prozesse (Basisprioritäten)

- Werte sind: idle, below normal, normal, above normal, high und real-time

... und (relative) Threadprioritäten

- Werte sind: time critical, highest, above normal, normal, below normal, lowest, idle

Aufruf von SetPriorityClass()

- bewirkt die Veränderung der Prioritätsklasse für alle Threads eines Prozesses

Aufruf von SetThreadPriority() - Threadpriorität kann aktiv verändert werden

- Nur innerhalb eines Prozesses

Prof. Dr. Peter Mandl Seite 26

Prioritäten unter Windows: Mapping

WinAPI-Prioritäten werden auf die interne Kernelprioritäten abgebildet

Hinweis: Prioritätsklasse eines Prozesses kann mit dem Taskmanager verändert werden

Testen: Testen Sie das Kommando „start /high notepad“

Prioritätsklasse

Windows-Thread-Priorität

real-time high above normal

normal

time critical 31 15 15 15

highest 26 15 12 10

above normal 25 14 11 9

normal 24 13 10 8

below normal 23 12 9 7

lowest 22 11 8 6

idle 16 1 1 1

...

Prof. Dr. Peter Mandl Seite 27

Prioritäten unter Windows: Vererbung

Ändert man die Priorität eines Prozesses, werden die Prioritäten der Threads ebenfalls geändert

System-Prozesse nutzen speziellen Systemcall NTSetInformationProcess

Taskmanager zeigt nur Basispriorität

Prozess 1

Thread 1

Prozess 1erzeugtProzess 2

Prozess 2 erbt Basispriorität von Prozess 1

Prozess 2 erzeugt Thread 1

Thread 1 erbt relative Basispriorität von Prozess 2

Thread hat auch eine dynamische Priorität (wird für das Scheduling genutzt)

SetPriorityClass()

SetThreadPriority()

Prozess hat nur eine Priorität

verändert Basispriorität des Threads

Verändert Prioritätsklasse des Prozesses und seiner Threads

Prozess 2

Prof. Dr. Peter Mandl Seite 28

Clock-Intervall und Quantum

Clock-Intervall

- ca. 10 ms bei x86 Singleprozessoren

- ca. 15 ms bei x86 Multiprozessoren

- siehe clockres-Tool zum Feststellen des Clock-Intervalls

Quantum

- Quantumszähler je Thread

• Auf 6 bei Workstations (Windows 2000, XP, ...) eingestellt

• Auf 36 bei Windows-Servern eingestellt

• Quantumszähler wird je Clock-Interrupt um 3 reduziert

Quantumsdauer = 2 (Workstation) bzw. 12 (Server) Clock-Intervalle

• 2 * 15 ms = 30 ms bei x86-Workstations

• 12 * 15 ms = 180 ms bei Servern

Prof. Dr. Peter Mandl Seite 29

Arbeitsweise des Schedulers: Szenario 1

Szenario: Priority Boost (Prioritätsanhebung) für Threads nach einer Ein-/Ausgabe-Operation

- Anhebung max. auf Priorität 15

- Treiber entscheidet

• Maus-/Tastatureingabe: +6

• Ende einer Festplatten-I/O: +1

x

Zeit

Priorität

Basis-

priorität

Zeitquantum

Thread aktiv

Thread wartet auf

Ein-/Ausgabe

...

Anhebung

der Priorität

X <= 15

Basispriorität

wieder erreicht

Verdrängung durch höher

priorisierte Threads jederzeit

möglich

Prof. Dr. Peter Mandl

Arbeitsweise des Schedulers: Szenario 2

Szenario: Rettung verhungernder Threads

Threads mit niedrigerer Priorität könnten benachteiligt werden

- Rechenintensive Threads höherer Priorität kommen immer vorher dran

Daher: Jede Sekunde wird geprüft, ob ein Thread schon länger nicht mehr dran war, obwohl er bereit ist

- Ca. 4 Sekunden nicht mehr dran?

- Wenn ja, wird er auf Prio. 15 gehoben und sein Quantum wird vervierfacht (ab Windows 2003) Prüfen

Danach wird er wieder auf den alten Zustand gesetzt

Also: Ein Verhungern wird vermieden!

Seite 30

Prof. Dr. Peter Mandl Seite 31

Arbeitsweise des Schedulers: Szenario 3

Szenario: Rettung verhungernder Threads

15

Zeit

Priorität

Basis-

priorität

Thread aktiv bei erhöhten

Quantum

Thread aktiv

Thread wartet auf

Ein-/Ausgabe

Thread wartet

auf Zuteilung

...

Anhebung der

Priorität

Windows 2000/XP: Verdoppelung

Windows 2003: Vervierfachung

Prof. Dr. Peter Mandl Seite 32

Einschub: Vergleich Linux - Windows

Kriterium Windows Linux O(1)-Scheduler

Unterstützte Prozesstypen

Timesharing- und Echtzeitprozesse; Unterscheidung über Priorität

Timesharing, Realtime mit FIFO, Realtime mit RR; Unterscheidung über Priorität

Prioritätsstufen Interne Kernelprioritätsstufen von 0 – 31: 0 – 15: Timesharing-Threads 16 – 31: Realtime- und System-Threads Eigene WinAPI-Prioritäten mit Basisprioritäten für Prozesse und Relativprioritäten für Threads

Statische und effektive Prioritäten mit Stufen von 0 – 139 (139 niedrigste): 0 – 99: Realtime-Prozesse 100 – 139: Timesharing-Prozesse

Scheduling-Strategie für Timeharing-Prozesse

Thread-basiert, Begünstigung von interaktiven vor rechenintensiven Threads Quanten, prioritätsgesteuert, Round Robin, Multi-Level-Feedback-Queue, 32 Queues

Prozess-basiert, Begünstigung von interaktiven vor rechenintensiven Prozessen (Thread = Prozess) Quanten, prioritätsgesteuert, Round Robin, Multi-Level-Feedback-Queue, 140 Queues

Prioritätenberechnung für Timesharing-Prozesse

Aktuelle Prioriät wird zur Laufzeit berechnet, Priority-Boost bei wartenden Threads nach Wartezeit oder bei GUI-Threads

Effektive Priorität wird zur Laufzeit berechnet, abhängig von statischer Priorität und einem Bonus (+/- 5) für lang schlafende Prozesse; Effektive Prio = statische Prio + Bonus (vereinfacht)

Quantumsberechnung für Timesharing-Prozesse

Quantumszähler = 6 bei Workstations und 36 bei Windows Servern, bei jedem Clock-Intervall wird Zähler um 3 dekrementiert; Clock-Intervall ist ca. 10 ms bei x86-Singleprozessoren (100 Hz) und ca. 15 ms (67 Hz) bei Multiprozessoren Quantumserhöhung bei GUI-Threads oder zum Vorbeugen vor Thread-Verhungern

Abhängig von statischer Priorität Quantum = (140 - statische Prio) * 20 [ms] (oder * 5) Maximum 800 ms Takt der internen Systemuhr von Linux bis Linux 2.5 auf 100 Hz einstellbar, ab Linux 2.6 auf 100, 250, 300, 1000 Hz; bei jedem Tick wird das Quantum der aktiven Prozesse um das Clock-Intervall reduziert

Prof. Dr. Peter Mandl

Einschub: Echtzeit- versus Universalbetriebssysteme

Echtzeitbetriebssystem: Embedded Linux, …

Universal-Betriebssystem: Windows, Linux, Unix, Mainframes, ...

Unterstützt harte Echtzeitanforderungen (Garantien, Deadlines)

Unterstützt nur “weiche” Echtzeitanforderungen (keine Garantien, keine Deadlines)

Ist auf den Worst-Case hin optimiert Optimierung auf die Unterstützung verschiedenster Anwendungsfälle hin, Reaktionszeit nicht im Vordergrund

Vorhersagbarkeit hat hohe Priorität bei der Auswahl des nächsten Tasks

Effizientes Scheduling mit fairem Bedienen von allen Prozessen, insbesondere von Dialogprozessen steht meist im Vordergrund

Meist werden wenige dedizierte Funktionen unterstützt

Viele Anwendungen können auf einem System laufen

Zeitoptimierung wichtig Durchsatz und Antwortzeitverhalten wichtig

Universalbetriebssysteme implementieren Mechanismen, die deterministische Umschaltungen erschweren:

Schedulingstrategien, Paging, Kernelmodus, Interruptbearbeitung, vorgegebene Zeitgranularitäten,…

Seite 33

Prof. Dr. Peter Mandl Seite 34

Überblick

1. Fallbeispiel: Unix

2. Fallbeispiel: Linux

3. Fallbeispiel: Windows

4. Fallbeispiel: Scheduling in Java

Prof. Dr. Peter Mandl

Scheduling in Java: Prioritäten

Scheduling auf Basis von Priorität und Zeitscheibe

Jeder Thread hat eine Priorität

Mögliche Prioritäten und deren Manipulation:

- siehe Attribut Thread.Max.Priority

- MIN, NORM, MAX

- setPriority()

- getPriority()

Thread mit hoher Priorität wird bevorzugt

Aber: Tatsächliche Priorisierung hängt von der JVM-

Implementierung ab

Seite 35

Prof. Dr. Peter Mandl Seite 36

Scheduling in Java: Strategien

Scheduling ist preemptive

- Thread wird nach einer bestimmten Zeit unterbrochen

(Zeitscheibe)

Scheduling ist „weak fair“:

- Irgendwann einmal kommt jeder Thread dran

Eine Queue je Priorität

- Thread der ganz vorne in Queue mit höchster Priorität

ist, kommt als nächstes dran

- Prioritäten werden für lange wartende Threads erhöht

Prof. Dr. Peter Mandl Seite 37

Überblick

Fallbeispiel: Unix

Fallbeispiel: Linux

Fallbeispiel: Windows

Fallbeispiel: Scheduling in Java

Prof. Dr. Peter Mandl Seite 38

Gesamtüberblick

Einführung in Computersysteme

Entwicklung von Betriebssystemen

Architekturansätze

Interruptverarbeitung in Betriebssystemen

Prozesse und Threads

CPU-Scheduling

7. Synchronisation und Kommunikation

8. Speicherverwaltung

9. Geräte- und Dateiverwaltung

10.Betriebssystemvirtualisierung