Computer-Systeme Teil 13: Konzept der Threadswi.f4.htw-berlin.de/users/messer/LV/WI-GWI-RABS/Folien/CS-13/13-C… · 3 Computer-Systeme – WS 12/13 - Teil 13/Threads 5 Zum Begriff

1

Computer-Systeme – WS 12/13 - Teil 13/Threads 02.01.2013 1

Computer-Systeme

Teil 13: Konzept der Threads

Computer-Systeme – WS 12/13 - Teil 13/Threads 2

Übersicht

• I/O als langsamster Vorgang• Threadwechsel mit der Resume-Operation• Verfeinerung der Systemaufrufe• Interrupts• Time Sharing• Scheduler

2


Motivation

• Die Geschwindigkeit der CPU und die der I/O-Geräte sind sehr unterschiedlich – ein Beispiel:– 1 Befehl sei mit 10 Takten durchgeführt,

d.h. bei einer Taktrate von 1 GHz benötigt ein Befehl 10 ns.– 1 Plattenzugriff liegt im günstigsten Fall bei 4ms (bei Laptop-

Platten bei 12ms).Dies bedeutet, dass die CPU während eines Plattenzugriffs in diesem Beispiel mind. 400.000 Instruktionen ausführen kann.

• Um die CPU während der I/O-Wartezeit zu nutzen, sollte diese Wartezeit mit der Abarbeitung anderer Programme zugebracht werden.


Zum Begriff des Prozesses und des Threads I

• Das führt zum Konzept der Threads und der Umschaltungzwischen Threads.

• In einem Thread läuft jeweils ein "Programm".

CPU-Status

RAM RAM

... ...

Thread T1

RAM

CPU-Status

CPU-Status

Thread T2 Thread TN

3


Zum Begriff des Prozesses und des Threads II

• Thread = Coroutine, Light weight Process = sequentiell ablaufende Software innerhalb eines Prozesses

• Ein Prozess ist ein Stück Speicher mit Daten und Code, dem eine CPU zugeordnet werden kann.

• Laufendes Programm = RAM (Daten, Code) + CPU-Status

CPU-Status

RAM

CPU-Status

RAM...

Thread T1 Thread T2

RAM

Prozess

CPU-Status


Das weitere Vorgehen

• Bevor dies erklärt werden kann, sind einige Vorarbeiten notwendig....

• Dann wird schrittweise in immer besser werdenden Versionen das endgültige Konzept aufgebaut.

• Aber:In der Praxis kommen auch alle Zwischenversionen vor.

4


Durchführung von I/O-Vorgängen

• Ein I/O-Vorgang wird durch Beschreiben von Geräteregistern gestartet.

• Die Beendigung eines I/O-Vorganges wird durch Abfragen des Status-Registers vom Gerät erkannt. Das Busy-Bit zeigt an, ob der aktuelle Vorgang beendet ist.

• Polling = Befragung des Geräts durch die CPU nach dem Status des aktuellen Vorgangs

• Busy Waiting = Ausschließliches Polling der CPU

Beschreiben der Geräteregister // Kommando an GerätWHILE Busy-Bit = 1 DO

; // keine OperationODErgebnis auswerten


Beispiel – Keyboard-Interface

Zitat aus http://www.lowlevel.eu/wiki/KBC

Busy-Bit

5


Bemerkungen I - Treiber

• Das Lesen/Schreiben von einzelnen Worten bei Massen-speichern ist viel zu ineffizient: es werden daher immer Blöcke von mindestens 1 Kbyte pro Vorgang mit DMA verarbeitet.

• Das Veranlassen eines I/O-Vorgangs wird auch als Absetzen eines I/O-Kommandos bezeichnet.

• Treiber (Device Driver) = Programmteile im Kernel, die Zugriff auf die Geräte-Register haben und Eigenarten der Geräte verdecken

• Die Treiber verdecken die speziellen Eigenschaften der Geräteregister (Aufbau, Kommandokodierung etc.) hinter einer einheitlichen Schnittstelle.

• Die Aufgabe der Treiber besteht darin, die I/O-Kommandos abzusetzen und deren Ergebnisse zu verarbeiten.


Bemerkungen II - Kernel

• Kernel = Speicherresidenter Teil des Betriebssystems• Der Kernel besteht aus Routinen, die gemeinsam von allen

anderen Komponenten (Threads, Prozesse) benutzt werden.

• Diese Routinen werden zum Beginn (Boot) in den RAM geladen und verbleiben dort bis zum Herunterfahren (Shutdown).

• Boot = Starten/Hochfahren eines Betriebssystems• Shutdown = Stoppen/Herunterfahren eines Betriebssystems

6


Das Problem und die Lösung

• Idee:Während des Wartens auf I/O arbeitet die CPU ein anderes Programm ab bis der I/O-Vorgang beendet ist; dann wendet sie sich wieder dem alten Programm zu. Dazu ist aber ein Prozess- oder Threadwechsel notwendig.

• Threadwechsel = Änderung der Zuordnung von Thread zur CPU, ohne Beeinträchtigung der betroffenen Threads

Das Problem besteht darin, dass die I/O-Geräte um mindestensden Faktor 400.000 langsamer als die CPU sind, so dass die CPU mit dem Busy Waiting sehr viel Zeit vergeudet.


Threadwechsel mit resume() I

• Es wird nun eine gedachte Operation Namens resume() definiert, die immer dann benutzt wird, wenn die CPU abgegeben werden muss.

• Das folgende beschreibt den Ablauf beim Threadwechselausgehend von einem Thread im User-Mode in einer Freistil-Notation:

Wechsel in den Kernel-ModusRette PC und SR // aktueller ThreadRette die allgemeinen Register------------ // WechselStelle allgemeine Register herStelle PC und SR herWechsel in den früher geretteten Modus // neuer Thread P

TRAP

RTT

7


Threadwechsel mit resume() II

Thread T1

......

......resume(T2);............resume(T2);......

Thread T2

......

......resume(T1);............resume(T1);......

Start(1)

(2)

(6)

(3) (4)

(5)

(8)

(9)(10)

(7)

Threadwechsel mit resume(p): beide Threads arbeiten im User-ModeNur während der Ausführung von resume() wird im Kernel-Modus gearbeitet.


Implementierung von resume() I

User-Mode

resume(Thread P){push(R0)R0:= Ptrap #1R0= pop()

}

Kernel-Mode

Trap-Handler#1(){push(All-registers-without-SP)store SP, SL in ThreadDescriptorselectThreaddeskriptor(R0)set new values of SP, SL All-registers-without-SP:= pop()rtt

}

Die Implementierung von resume() erfolgt in zwei Teilen:der erste für den User-Mode, der zweite für den Kernel-Mode.

Das Register R0 wird zur Übergabe des Parameters benutzt und muss gerettetwerden. Nach der Rückkehr zum alten Programm wird R0 wieder hergestellt.

(A)

(B)

8


Implementierung von resume() II

Parameter P

Return-Address

Status-Register

Return-Address

R0

<- SP

Stack von T1

Situation zum Beginnder Trap-Handlers (A)

Situation bei Abgabeder Kontrolle (B)

GeretteteRegister

Parameter P

Return-Address

Status-Register

Return-Address

R0

<- SP

Stack von T1


Implementierung von resume() III

GeretteteRegister

Parameter P

Return-Address

Status-Register

Return-Address

R0

<- SP

<- SP

Situation vor Annahmeder Kontrolle (B) durch T2

T2 hat wieder dieKontrolle

Stack von T2 Stack von T2

Parameter P

Return-Address

R0

9


Beispiel-Situation I

GeretteteRegister

Parameter P

Return-Address

Status-Register

Return-Address

R0

<- SP

Thread1

GeretteteRegister

Parameter P

Return-Address

Status-Register

Return-Address

R0

<- SP

Thread2

GeretteteRegister

Parameter P

Return-Address

Status-Register

Return-Address

R0

<- SP

ThreadN

<- SP

Thread3

schläft schläft schläftläuft


Beispiel-Situation II

• Ein Thread hat zwei mögliche Zustände:– Er schläft – ist komatös– Er läuft

• Ein Thread kann nicht bemerken, wie häufig er schläft, denn bei jeder Abgabe der CPU wird sein gesamter Zustand gerettet und später wieder hergestellt.

• Jeder schlafende Thread sieht vom Oberteil des Stacks her gesehen immer gleich aus: dort steht der CPU-Status

Es fehlt noch die Verwaltung von Threads…

10


Thread-Verwaltung I

• Jeder Thread wird mit einem Threaddeskriptor verwaltet: • Aufbau des Threaddeskriptors:

– Identifikation/Name in Form einer Nummer– Verbrauchte CPU-Zeit– Priorität– etc.

• Die Zusammenfassung aller Deskriptoren in einer Tabelle wird Threadtabelle genannt.

Wir werden später nach der Einführung der Prozesse von einemProcessdeskriptor sprechen.Die Tabelle heißt dann Prozesstabelle oder Tasktabelle.Es handelt sich aber um dieselbe Tabelle.


Thread-Tabelle I

• Die verbrauchte Zeit wird in Ticks gemessen; ein Tick entsprichtca. 1ms.

• Jeder Thread erhält eine eigene eindeutige Nummer – es könnte auch der Index in der Tabelle threadTbl[] sein.

• Die Priorität ist ein Wert, der bei Konflikten den Vorrang definiert.

• Das Layout definiert die Bereiche im Speicher: Code, Daten

struct Thread { // 1. Versionint id; // Nummerint prio; // Prioritätint usedTime; // Verbrauchte CPU-Zeit in TicksThreadLayout data; // Datensegment

}

Thread threadTbl[MAX_THREADS]

11


Thread-Tabelle II - ThreadLayout

• Jeder Thread arbeitet in einem eigenen Daten-bereich (Segment).

• Jeder Thread hat eigene Werte von SP, SL, min und max.

• Im ThreadLayout-Deskriptor werden diese Werte abgespeichert.

n

Stack

max

Hea

p

SP->

Vorbelegt

Reserviert

Environment

SL->

min

struct ThreadLayout {// 1. Versionaddress min; // Untere Adresseaddress max; // Obere Adresseaddress SP; // Wert von SPaddress SL; // Wert von SL

}


Speicher-Layout für mehrere Threads I

n

Stack

max

Hea

p

SP->

Vorbelegt

Reserviert

Environment

SL->

min

n

Stack

max

Hea

p

SP->

Vorbelegt

Reserviert

Environment

SL->

min

n

Stack

max

Hea

p

SP->

Vorbelegt

Reserviert

Environment

SL->

min… … …

Thread1 Thread2 ThreadN

Code

12


Speicher-Layout für mehrere Threads II

• In der Thread-Verwaltung liegen die Tabelle mit den Deskriptoren.

• Der Bereich der Geräte-Register sowie die Trap-Vektoren(Tabellen zur Definition der Trap-Handler) wurden hier weggelassen.

CodeDaten

Thread1

DatenThread2

Thread-Verwaltung

DatenThreadN

…

0 max

Aufbau des gesamten RAMs bei Verwenudng von Threads


Systemaufruf – Verfeinerung I

• Ein Systemaufruf ist das Aufrufen einer Routine des Kernels, die im Kernel-Modus der CPU abläuft.

• Ein Systemaufruf ist vollkommen analog zum Aufruf einer Routine – so wie bisher behandelt.

Warum ist der Kernel-Modus erforderlich?

Der Zugriff auf die Geräte-Register bzw. das Ausführen vonI/O-Instruktionen ist nur in diesem Modus möglich.

13


Systemaufruf – Verfeinerung II

• resume() betrifft den Fall, dass ein Threadwechsel aus einem laufenden Prozess zu einem anderen laufenden Prozess stattfindensoll.

• Ein Systemaufruf ohne Threadwechsel läuft sehr ähnlich zu resume() ab.Hier der prinzipielle Ablauf:

Verkürzter Ablauf bei Syscall(Name, Parameter)Wechsel in den Kernel-ModusRette PC und SR // aktueller ThreadRette die allgemeinen Register // aktueller Thread.....Führe den Systemaufruf Name mit Parameter aus.....Stelle allgemeine Register her // aktueller ThreadStelle PC und SR her // aktueller ThreadWechsel in den User-Modus

TRAP

RTT


Das Ganze mit Busy Waiting (Ablauf)

Wechsel in den Kernel-ModusRette PC und SR // aktueller ThreadRette die allgemeinen Register // aktueller Thread.....Beschreiben der Geräteregister // Kommando an GerätWHILE Busy-Bit = 1 DO

; // keine OperationODErgebnis auswerten.....Stelle allgemeine Register her // aktueller ThreadStelle PC und SR her // aktueller ThreadWechsel in den User-Modus

TRAP

RTT

Verkürzter Ablauf bei Syscall(Name, Parameter)

14


Implementierung von Systemaufrufen

User-Mode

syscall(Nummer,Param) = {push(R0)R0:= Nummertrap #1R0= pop()

}

Kernel-Mode

Trap-Handler#1() = {push(All-registers-without-SP)Hole Syscallnummer von R0Hole ParameterCall R0(Parameter)All-registers-without-SP:= pop()rtt

}


Threadwechsel innerhalb des Systemaufrufs

• Wenn nun ein Syscall mit I/O, z. B. Lesen von einer Platte, durchgeführt wird, wird der erste Teil des resume() durch den Syscallausgeführt.

• Der Threadwechsel findet dann im Code des Systemaufrufs statt, wobei die Operation continue(Thread) die zweite Hälfte des resume() realisiert.

• Nun kann ein Threadwechsel bei jedem Warten realisiert werden:

// während des Syscalls im KernelSetzen der Geräteregister // Absetzen eines KommandosWHILE Busy-Bit = 1 DO

continue(Thread) // CPU abgebenODErgebnis auswerten.....

15


continue() I

Rette PC und SR // explizit im KernelRette die allgemeinen Register // aktueller Thread------------ // WechselStelle allgemeine Register herStelle PC und SR her // aktueller ThreadWechsel in den geretteten Modus // neuer Thread P

RTT

Verkürzter Ablauf von continue(Thread P):

• continue() ist eine Variante von resume(), bei der zum Beginn keineTrap-Instruktion ausgeführt wird.Daher wird zum Beginn das Stacklayout einer Trap-Instruktionnachgebaut, so dass es so aussieht als ob ein Trap ausgeführt wurde.

• Nach Beendigung von continue(Thread P) wird der andere Thread P direkt nach dessen letzten resume() bzw. continue() fortgesetzt.


continue() II – ein Beispiel

(3): Wechsel Kernel- -> User-Mode, (5), (7), (9) Wechsel innerhalb des Kernel-Modes

Thread p1............Syscall(...)

....continue(p2);....

......Syscall(...)


......

Start(1)

(2)

(6)

(3)(4)

(5)

(8)

(9)(10)

(7)

Prozesswechsel innerhalb von Systemaufrufen

Thread p2............Syscall(...)


......Syscall(...)


......

User-Mode

Kernel-Mode

16


continue() und resume()

• Mit continue() wird innerhalb des Kernels ein Wechsel durchgeführt.

• Mit resume() wird aus dem User-Mode in den Kernel zwecks Wechsel des Threads gewechselt; im Kernel findet der Wechsel statt, der dann mit der Rückkehr in den User-Mode des neuen Threads endet.

• Ein Syscall beginnt immer mit einem Wechsel in der Kernelund endet mit einer Rückkehr in das aufrufende Programm.

• Während des Syscalls im Kernel können andere Threads per continue() aktiviert werden; aber irgendwann wird der Syscall beendet.


Implementierung von continue() I

(1)temp:= pop() //return-address(2)push SR(3)push temp(4)push(All-registers-without-SP)

store SP, SL in ThreadDescr.--- WechselselectThreaddeskriptor(P)set new values of SP, SL All-registers-without-SP:= pop()rtt

Return-Address <- SP

Parameter P

Vor (1)Das ist die normale Situation eines Aufrufs.

Ablauf von continue(Thread P):

17


Implementierung von continue() II

<- SPParameter P

SR <- SP

Parameter P

Vor (2) Vor (3)

(1)temp:= pop()(2)push SR(3)push temp(4)push(All-registers-without-SP)

store SP, SL in ThreadDescr.--- WechselselectThreaddeskriptor(P)set new values of SP, SL All-registers-without-SP:= pop()rtt

Ablauf von continue(Thread P):


Implementierung von continue() III

SR

<- SP

Parameter P

Return-Address

Vor (4) Nach (4)

GeretteteRegister

SR

<- SP

Parameter P

Return-Address

Zielstruktur

GeretteteRegister

Return-Address

Status-Register

<- SP

CPU-Status

Parameter P

Wenn der Thread später wiederdie Kontrolle bekommt, springter direkt an die Stelle nach demAufruf von continue().

18


Implementierung von continue() IV

• War die letzte Aktion des nächsten Threads ein continue(), so wird dieser Thread im Kernel fortgesetzt – ab der Stelle nach diesem continue().

• War die letzte Aktion des nächsten Threads ein resume(), d.h. dieser Thread hat die Kontrolle im Kernel-Teil des resume() abgegeben, wird dieser Teil fortgesetzt und in den User-Mode gewechselt.

• Der CPU-Modus des nächsten Threads wird durch den SR-Wert vom Stack bestimmt, da dieser Wert von der RTT-Instruktion benutzt wird.

• Das wird dadurch erreicht, dass in allen Fällen derselbe Stackaufbau an der Stackspitze benutzt wird.


Threads weiter

• Jeder Thread besteht damit aus zwei Teilen:A) das normale Programm im User-ModeB) Routinen im Kernel

• mit dem Unterschied, dass die Routinen im Kernel gemeinsam von allen Threads benutzt werden.

Code

DatenThread1Daten

Thread2DatenThreadN

Kernel-Mode User-Mode

19


Also…

• Wird kein I/O gemacht, so sollten sich die Threads in dieser Version gegenseitig per resume() aufrufen (so wie zum Anfang).

• resume() wird wie ein Syscall ohne I/O behandelt.• Syscalls ohne I/O rufen nie continue() auf.• Alle Syscalls mit I/O rufen immer continue() auf.

continue() aktiviert einen anderen Thread, der im Kernel ist.

Aber: alle nicht-aktiven Threads sind immer im Kernel. Warum?


Busy Waiting mit continue() (Ablauf)

Wechsel in den Kernel-ModusRette PC und SR // aktueller ThreadRette die allgemeinen Register // aktueller Thread.....Beschreiben der Geräteregister // Kommando an GerätWHILE Busy-Bit = 1 DO

continue(Thread) // CPU abgebenODErgebnis auswerten.....Stelle allgemeine Register her // aktueller ThreadStelle PC und SR her // aktueller ThreadWechsel in den User-Modus

TRAP

RTT

Warum immer noch die While-Schleife?Weil der Thread vorzeitig die Kontrolle bekommen kann

20


Scheduler I

Doch es gibt ein Problem:

Der Thread, der zu warten beginnt, d.h. der continue-Aufrufer,muss wissen, welche Threads existieren und welcher von diesenfür die Fortsetzung ausgewählt werden soll.

Lösung: Es wird dann zu einem Thread Namens Schedulergewechselt, der den nächsten Thread bestimmt.


Scheduler II

• In der Threadtabelle mitschreiben, welche Threads existieren• Vermerken, welcher Thread zu welchem Anteil die CPU schon

bekommen hat• Vermerken des Thread-Zustandes (state):

– Running: Thread hat gerade die CPU– Ready: Thread wartet auf CPU– Waiting: Thread wartet auf Beendigung von I/O– Sleeping: Thread benötigt irgendwann später die CPU

• Ändern des Threadzustands entsprechend einer neuen Situation

• Dem nächsten Thread die CPU zuteilen

Der Scheduler ist ein Thread innerhalb des Kernels, der für folgende Aufgaben zuständig ist:

21


Scheduler III

• Scheduler = Thread, der die Zuteilung der CPU zu den Threads nach einem Verfahren (Scheduling Strategie) realisiert

• In der Threadtabelle sind die dafür notwendigen Informationen untergebracht.

struct Thread { // 2. Versionint id; // Nummerint state; // Zustandint prio; // Prioritätint usedTime; // TicksThreadLayout data; // Datensegment

}

Thread threadTbl[MAX_THREADS]


Scheduler IV

Thread p1............

continue(Scheduler);............

continue(Scheduler);......

Thread p2............

continue(Scheduler);............

continue(Scheduler);......

Start

(1) (3)

(5) (7)

(9)

Thread Schedulerwhile true do

look_for_next;continue(Thread);

od;Kernel-Mode

User-Mode

(2), (4), (6), (8), (10)

22


Bemerkungen

• Der Scheduler ist ein Thread, der permanent im Kernelarbeitet – es gibt für ihn keinen User-Mode.

• Der Scheduler ist als Endlos-Schleife programmiert, die solange durchlaufen wird, bis ein Thread gefunden wird, der die CPU bekommen kann, d.h. im Zustand ready ist.

• Immer dann, wenn ein Thread im Kernel-Mode auf irgendetwas warten muss, wird ein continue() zum Scheduler gemacht.

• In dieser Version verbleibt der Thread im Zustand ready, wenn er auf ein Gerät wartet. Das ist der Grund, dass ein Thread zu früh die CPU bekommt: daher die WHILE-Schleife.


Da sind noch zwei kleine Probleme...

1. Es ist immer noch das Polling (Nachsehen, ob der I/O-Vorgang beendet ist) notwendig. Dies ist zwar schon reduziert, aber immer noch vorhanden.

2. Eine Endlosschleife ohne ein Syscall/Continue eines einzigen Threads bringt das gesamte System zum Hängen, da nur mit der Beendigung des Ganzen dieser eine Thread beendet werden kann. Besser ist, dass nur der Thread mit der Endlosschleife getrennt von den übrigen beendet wird.

23


Unterbrechungen (Interrupts)

• Wenn ein I/O-Gerät seine Operation beendet hat, sendet es über den Bus ein Signal, das von der CPU als Unterbrechung (Interrupt) behandelt wird.

• Empfängt die CPU dieses Signal, so passiert folgendes:– Die Ausführung der aktuellen Instruktion wird beendet.– Anstatt die nächste Instruktion auszuführen, wird eine Trap-

Instruktion ausgeführt.

• Die Behandlung im Kernel besteht in der Ausführung einer für diesen Interrupt speziellen Routine, dem Interrupt-Handler (Unterbrechungsbehandler).Dieser tut folgendes:– Feststellen, welches Gerät die Unterbrechung signalisierte– In der Threadtabelle alle Threads, die auf diese Unterbrechung

warteten, in den Zustand Ready bringen


Ablauf beim Interrupt - Version 1 (Ablauf)

• In dieser Version wird das aktuell laufende Programm lediglich unterbrochen und nach dem Ändern der Threadtabelle wieder fortgeführt, d.h. es findet kein Threadwechsel statt.

• Der Interrupt kann auftreten, wenn die CPU im User-Modus ist oder auch im Kernel-Modus!

• Dies hat den Nachteil, dass Threads, die auf den Interrupt lange gewartet haben, noch weiter warten müssen.

Wechsel in den Kernel-Modus // wie bei Trap-InstruktionRette PC und SRRette die allgemeinen RegisterBestimme signalisierendes GerätSetze wartende Prozesse auf ReadyStelle allgemeine Register her // alte WerteStelle PC und SR her // alte WerteWechsel in den geretteten Modus

INT

RTI

24


Ablauf beim Interrupt - Version 2 (Ablauf)

• In dieser 2. Version wird direkt nach dem Bearbeiten der Thread-tabelle zum Scheduler gewechselt, der dann entscheidet, mit welchem Thread es weiter geht.

• Der Scheduler durchsucht bei jedem seiner Aufrufe die Threadtabellenach Threads im Zustand "Ready", um einen von diesen auszuwählen. Alle anderen Threads werden von ihm ignoriert.

• Damit dies funktioniert, muss der Interrupt-Handler dasselbe Stacklayout an der Stackspitze hinterlassen wie beim Syscall, Trap etc.

Wechsel in den Kernel-ModusRette PC und SRRette die allgemeinen Register // auch User-SPBestimme signalisierendes GerätSetze wartende Prozesse auf Readycontinue(Scheduler)

INT


Die beiden Behandlungsmöglichkeiten

Thread T1

Scheduler

Thread T2

Scheduler

Handler

Thread T1

HandlerInterrupt

Handler wirdbeendet

Interrupt

25


Warten auf I/O mit Interrupts

• Der Thread setzt sich freiwillig auf eine Warteliste, indem er in den Zustand "Waiting" geht. Ein I/O-Deskriptor beschreibt das Gerät bzw. den Vorgang, auf den der Thread wartet.

• Wenn der Interrupt-Handler dieses Geräts aktiviert wird, werden alle mit dessen I/O-Deskriptor wartenden Threads in den Status "Ready" gesetzt.

Thread Tn.....Beschreiben der Geräteregister;wait(I/O-Descriptor);Ergebnis auswerten;.....

PROC wait(I/O-Descriptor)Setze Thread Status("Waiting");Setze I/O-Descriptor in Tabelle;continue(Scheduler);

struct I/O-Descriptor {Address SR-Register;int Busy-Bit-Number;

}


Damit ist das erste Problem gelöst....

• Durch den Mechanismus des Interrupts entfällt vollkommen das Polling und damit auch das Busy Waiting.

• Ein auf I/O wartender Thread wird erst dann aktiviert, wenn der I/O-Vorgang beendet ist.Besser geht es nicht mehr.

• Was passiert, wenn alle Threads auf I/O warten?Ganz einfach: dann findet der Scheduler keinen Thread, den er aktivieren kann und durchsucht in einer Endlos-schleife seine Tabelle bis er selbst durch einen Interruptunterbrochen wird. Dieser Interrupt-Handler setzt dann einen der Threads auf "Ready" und aktiviert den Scheduler; und der findet dann, was er sucht.

26


Time Sharing Verfahren I

• Mit den vorgestellten Mechanismen lassen sich alle Nachteile bis auf die "Ungerechtigkeiten" bei der CPU-Vergabe sowie bis auf den Fall der Endlosschleifen beseitigen. Das letztere Problem wird durch einen Timer gelöst.

• Ein Timer ist ein spezielles I/O-Gerät, das nach einer eingestellten Zeit bzw. in zyklischen Abständen einen speziellen Interrupt sendet. Dieser wird immer mit dem Aktivieren des Schedulers aus dem Handler heraus behandelt.

• Zeitscheibe = Zeitdauer zwischen zwei Timer-Interrupts

• Nach Ablauf einer Zeitscheibe kann damit der Scheduler die CPU an einen anderen Thread geben, unabhängig davon, ob ein I/O-Vorgang erfolgt ist oder nicht.


Time Sharing Verfahren II

• Time Sharing Verfahren = Verfahren der Vergabe der CPU nach Ablauf einer Zeitspanne (Zeitscheibe)

• Den Threads wird die CPU nach Ablauf der Zeitscheibe entrissen.

• Macht ein Thread I/O, so gibt er die Zeitschreibe früher ab.

27


Schedulingverfahren I

• Die Strategie nach der ein Scheduler die CPU an konkurrierende Threads vergibt heißt Schedulingverfahren.

• Es gibt – langfristige Planungen– kurzfristige Priorität- gesteuerte Verfahren

• Besonders schwierig sind Verfahren, die eine Reaktion der Maschine innerhalb einer sehr kurzen Zeit garantieren müssen: Real Time Scheduling.


Schedulingverfahren II – Zwei Beispiele

• Zyklisches FIFO (First In First Out) oder Round-Robin:Den Threads wird zirkulär hintereinander die CPU gegeben, wobei die Zeitscheiben in der Regel gleich lang sind.

• High Priority First– Alle Threads haben eine Priorität.– Threads mit der höchsten Priorität werden bevorzugt.– Threads mit niedriger Priorität bekommen nur dann die CPU,

wenn alle höherwertigen Threads im Status "Waiting" oder nicht vorhanden sind.

• Mischform: Priorisiertes Round-Robin

28


Schedulingverfahren III

Proc P1 Proc P2 Proc Pn

Round Robin

Proc P1 Proc P2 Proc PnPrioritätsklasse 1

Proc P1 Proc P2 Proc PnPrioritätsklasse 2

Round Robinmit Prioritäts-klassen


Nach dieser Anstrengung etwas Entspannung....

Documents

Computer-Systeme Teil 13: Konzept der Threadswi.f4.htw-berlin.de/users/messer/LV/WI-GWI-RABS/Folien/CS-13/13-C… · 3 Computer-Systeme – WS 12/13 - Teil 13/Threads 5 Zum Begriff