Computersystemen 2

HOGESCHOOL ROTTERDAM / CMI
Computersystemen 2
(TIRCCMS02 - Operating systems)
[email protected]
HOGESCHOOL ROTTERDAM / CMI
2 Processen
HOGESCHOOL ROTTERDAM / CMI
Processen
Een proces is een abstractie van een
programma in uitvoering.
(Bij een process horen naast het programma ook input, output en
toestandsvariabelen)
L.V. de Zeeuw
Computersystemen 2
3
HOGESCHOOL ROTTERDAM / CMI
2.1Een
inleiding in processen
Moderne computers kunnen op het zelfde tijdstip verschillende dingen
uitvoeren:
• Programma(‘s) van een gebruiker
• Printen
• Lezen van schijf
Steeds schakelt de CPU over van het ene programma naar het andere
programma …
De gebruiker krijgt het idee dat aan meerdere dingen parallel wordt
gewerkt …
Men spreekt over pseudo-parallellisme.
Het goed bijhouden van meerdere parallelle activiteiten is een moeilijke
opgave. Een model voor parallellisme is onderwerp van dit college.
L.V. de Zeeuw
Computersystemen 2
4
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
procesmodel (1/4)
Alle software (ook het operating system
zelf) die op een computer kan worden
uitgevoerd is een verzameling
processen.
Multiprogrammering is het snel
verplaatsen van de aandacht van de
CPU van het ene naar het andere
proces.
L.V. de Zeeuw
Computersystemen 2
5
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
L.V. de Zeeuw
procesmodel (2/4)
Computersystemen 2
6
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
procesmodel (3/4)
Wanneer de CPU zijn aandacht over
processen verdeelt is de snelheid
waarmee een proces de benodigde
berekeningen uitvoert niet steeds gelijk.
L.V. de Zeeuw
Computersystemen 2
7
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
procesmodel (4/4)
Verschil proces en programma.
• Een proces is één of ander activiteit.
• Bij een proces horen naast het programma ook input,
output en toestandsvariabelen
• Een CPU wordt door meerdere processen gedeeld.
Een scheduling algoritme bepaald wanneer de CPU
switched naar een andere proces.
L.V. de Zeeuw
Computersystemen 2
8
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
procesmodelProceshiërarchieën (1/2)
• In eenvoudige systemen kunnen alle noodzakelijke
processen in één keer worden gestart.
• In de meeste systemen worden processen gestart of
beëindigd wanneer daar behoefte aan is.
L.V. de Zeeuw
Computersystemen 2
9
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
procesmodelProceshiërarchieën (2/2)
Een operating system kent system calls voor het creëren en
beëindigen van processen.
Unix: fork()
• Fork() creëert een identieke kopie van het proces dat de system
call aanroept.
• Het kind proces kan ook weer met fork() een proces creëren.
• Zo ontstaat een boomstructuur van processen.
• Elk proces heeft:
– Slecht één ouder proces
– Nul of meer kind processen
L.V. de Zeeuw
Computersystemen 2
10
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
procesmodel-
Toestanden van processen (1/4)
cat hs1 hs2 hs3 | grep tree
Cat voegt 3 files samen die door grep worden doorzocht
op het woord tree.
Als cat nog niet klaar is met samenvoegen moet grep
wachten.
Grep wordt geblokkeerd.
N.B. Processen kunnen communiceren
L.V. de Zeeuw
Computersystemen 2
11
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
procesmodel-
Toestanden van processen (2/4)
Een proces wordt geblokkeerd indien een
proces logische gezien niet verder kan:
• Het proces moet wachten op input
• Een andere proces krijgt voorrang
L.V. de Zeeuw
Computersystemen 2
12
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
procesmodel-
Toestanden van processen (3/4)
Running
1
3
2
Blocked
Ready
4
L.V. de Zeeuw
1. Een proces moet
wachten op invoer.
2. De scheduler wijst de
CPU toe aan een
ander proces.
3. De scheduler wijst de
CPU toe aan een
proces.
4. Er is invoer
beschikbaar.
Computersystemen 2
13
HOGESCHOOL ROTTERDAM / CMI
2.1.1Een
procesmodel-
Toestanden van processen (4/4)
L.V. de Zeeuw
Computersystemen 2
14
HOGESCHOOL ROTTERDAM / CMI
2.1.2De
implementatie van
processen (1/6)
• De proces ‘administratie’ wordt
bijgehouden in de procestabel.
• De procestabel wordt gebruikt door
– Procesbeheer
– Geheugenbeheer
– Beheer van het file system
L.V. de Zeeuw
Computersystemen 2
15
HOGESCHOOL ROTTERDAM / CMI
2.1.2De
implementatie van
processen (2/6)
L.V. de Zeeuw
Computersystemen 2
16
HOGESCHOOL ROTTERDAM / CMI
2.1.2De
implementatie van
processen (3/6)
L.V. de Zeeuw
Computersystemen 2
17
HOGESCHOOL ROTTERDAM / CMI
2.1.2De
implementatie van
processen (4/6)
L.V. de Zeeuw
Computersystemen 2
18
HOGESCHOOL ROTTERDAM / CMI
2.1.2De
implementatie van
processen (5/6)
• Stack (stapel)
• LIFO =
Last In First Out
• De stackpointer
(SP) wijst het
adres aan van
gebruikte
geheugenplaats.
L.V. de Zeeuw
Computersystemen 2
19
HOGESCHOOL ROTTERDAM / CMI
2.1.2De
implementatie van
processen (6/6)
L.V. de Zeeuw
Computersystemen 2
20
HOGESCHOOL ROTTERDAM / CMI
2.2Communicatie
tussen
processen (1/1)
Processen communiceren met andere processen.
Voorbeeld:
Als een proces een file wil lezen moet dit aan het
‘fileproces’ duidelijk worden gemaakt.
Daarna moet het ‘fileproces’ aan het ‘diskproces’
doorgegeven welk block moet worden gelezen.
Interproces Communicatie (IPC)
L.V. de Zeeuw
Computersystemen 2
21
HOGESCHOOL ROTTERDAM / CMI
2.2.1Race-condities
(1/2)
• Processen kunnen gebruik maken van een
gemeenschappelijk deel van het geheugen.
• Men spreekt van race-condities wanneer twee of
meer processen een gemeenschappelijk deel van het
geheugen gebruiken voor lezen en/of schrijven en
het uiteindelijke effect afhangt van welk proces
wanneer wordt uitgevoerd.
• Een race-conditie is ongewenst. De uitkomst van een
proces wordt onvoorspelbaar en is afhankelijk van de
volgorde of timing van gebeurtenissen
L.V. de Zeeuw
Computersystemen 2
22
HOGESCHOOL ROTTERDAM / CMI
2.2.1Race-condities
(2/2)
Pointer naar eerst
volgende af te drukken
file
Spooler directory
next_free_slot
next_free_slot:=
next_free_slot+1
in:=next_free_slot
Pointer naar vrije
plaats
Next_free_slot
next_free_slot:=
next_free_slot+1
in:=next_free_slot
L.V. de Zeeuw
IN en OUT zijn
toegankelijk voor proces
A en proces B
Computersystemen 2
23
HOGESCHOOL ROTTERDAM / CMI
2.2.2Kritieke
gebieden (1/3)
Hoe voorkomen we race-condities?
Wanneer een proces een gemeenschappelijk
gegeven of gemeenschappelijke file gebruikt
wordt een ander proces van gebruik
uitgesloten.
(wederzijdse uitsluiting of mutulal exclusion)
L.V. de Zeeuw
Computersystemen 2
24
HOGESCHOOL ROTTERDAM / CMI
2.2.2Kritieke
gebieden (2/3)
Geschikte instructies om wederzijdse uitsluiting mogelijk
te maken is een belangrijke ontwerpkeuze voor elke
operating system.
Instructies die bewerkingen op gemeenschappelijke
gegevens of files uitvoeren bevinden zich in
zogenaamde kritieke gebieden (critical sections)
Race-condities kunnen dan worden voorkomen door
niet toe te staan dat twee of meer processen zich
tegelijkertijd in hun kritieke gebied bevinden.
L.V. de Zeeuw
Computersystemen 2
25
HOGESCHOOL ROTTERDAM / CMI
2.2.2Kritieke
gebieden (3/3)
Voor het correct en efficiënt laten samen werken van
processen is nodig:
1. Er mogen nooit twee processen tegelijkertijd in hun
kritieke gebied zijn.
2. Er mogen géén aannamen worden gedaan over de
relatieve snelheden van de betrokken processen of
het aantal beschikbare CPU’s
3. Een proces buiten zijn kritieke gebied mag een
ander proces niet blokkeren.
4. Een proces mag niet oneindig lang wachten voordat
het zijn kritieke gebied mag betreden.
L.V. de Zeeuw
Computersystemen 2
26
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (1/15)
Een proces mag niet zijn kritieke gebeid betreden als
een ander proces in zijn kritieke gebied bezig is het
gemeenschappelijk deel van het geheugen te
veranderen.
Te onderzoeken (mogelijke) oplossingen:
• Het uitschakelen van interrupts
• Variabelen met slot functie
• Nauwgezette afwisseling van kritieke gebieden
• De oplossing van Peterson
• De instructie TSL
L.V. de Zeeuw
Computersystemen 2
27
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (2/15)
Het uitschakelen van
interrupts
• Ieder proces zal na het
betreden van zijn
kritieke gebied alle
interrupts uitschakelen.
• Net voor het verlaten
van het kritieke gebied
wordt het interrupt
mechanisme weer
ingeschakeld.
L.V. de Zeeuw
Computersystemen 2
28
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (3/15)
Het uitschakelen van interrupts
Nadelen
•
•
Het is niet handig dit aan een proces over
te laten. Als een proces ‘vergeet’ het
interrupt mechanisme weer aan te zetten
betekent dit het ‘einde’ van het systeem
Werkt niet voor een systeem met
meerder CPU’s (als voor een CPU de
interrupts worden uitgezet kunnen
processen die een andere CPU
gebruiken nog steeds bij het kritieke
gebied)
Voor de kernel is het uitzetten van interrupts
wel bruikbaar mechanisme.
L.V. de Zeeuw
Computersystemen 2
29
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (4/15)
Variabelen met slot functie
Gebruik één gedeelde variabele: slot
Deze variabele wordt initieel op 0 gezet.
• Bij het betreden van het kritieke gebied wordt eerst het slot
getest.
• Als slot 0 is dan wordt slot op 1 gezet en wordt het kritieke
gebied betreden.
• Bij het verlaten van het kritieke gebied wordt slot weer op 0
gezet.
• Als slot de waarde 1 heeft wacht het proces tot slot weer de
waarde 0 heeft (een proces is bezig in zijn kritieke gebied).
L.V. de Zeeuw
Computersystemen 2
30
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (5/15)
Variabelen met slot functie
Nadeel
Ook hier kan een race conditie optreden
• Proces A leest slot en vindt 0
• Proces B leest vrijwel tegelijkertijd slot en vindt ook 0
• Zowel proces A als proces B veranderen slot in 1
Nu bevinden zich twee processen zich in hun kritieke gebied.
L.V. de Zeeuw
Computersystemen 2
31
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (6/15)
Nauwgezette afwisseling van kritieke gebieden
L.V. de Zeeuw
Computersystemen 2
32
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (7/15)
Nauwgezette afwisseling van kritieke gebieden
Een variable turn geeft aan welk proces aan de beurt is om zijn kritieke gebied te
betreden.
Turn heeft initieel de waarde 0.
•
•
•
•
•
Proces A leest turn en vindt 0
Proces A betreedt zijn kritieke gebied.
Proces B leest turn en vindt óók 0.
Proces B wacht in een herhalingslus (busy-waiting) totdat turn 1 is.
Wanneer proces A zijn kritieke gebied verlaat verandert hij turn in 1 en kan
proces B zijn kritieke gebied betreden.
L.V. de Zeeuw
Computersystemen 2
33
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (8/15)
Nauwgezette afwisseling van kritieke
gebieden
•
•
•
•
•
•
Stel dat proces B zijn kritieke gebied snel
doorloopt zodat beide processen in het
niet-kritieke gebied zitten en turn de
waarde 0 heeft.
Nu doorloopt proces A zijn kritieke gebied
snel en komt terug in zijn niet-kritieke
gebied.
Turn heeft nu de waarde 1
Proces A maakt zijn niet-kritieke deel snel
af en gaat terug naar het begin van de
herhalingslus.
Proces A mag nu niet zijn kritieke gebied
betreden omdat hij zelf turn de waarde 1
heeft gegeven.
Proces B is nog steeds ‘op zijn gemak
bezig’ zijn niet kritieke deel af te ronden…
L.V. de Zeeuw
Ieder proces om de beurt
toegang geven tot zijn kritieke
gebied is niet goed als het ene
proces veel langzamer is dan
het andere proces
Computersystemen 2
34
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (9/15)
Nauwgezette afwisseling van
kritieke gebieden
Dit is ook in strijd met voorwaarde 3
3. Een proces buiten zijn kritieke gebied
mag een ander proces niet blokkeren.
L.V. de Zeeuw
Computersystemen 2
35
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (10/15)
De oplossing van Peterson
De Nederlandse wiskunde T. Dekker bedacht:
Combineer:
• Variabelen met slot functie
• Nauwgezette afwisseling van kritieke gebieden
• Dit was de eerste software oplossing voor het
probleem van wederzijdse uitsluiting.
• De oplossing van Dekker was ingewikkeld.
• In 1981 ontdekte Peterson een veel eenvoudiger
variant.
L.V. de Zeeuw
Computersystemen 2
36
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (11/15)
De oplossing van Peterson:
• Voordat het kritieke gebied wordt betreden roept elk
proces de procedure enter_region aan.
• Als parameter wordt het eigen procesnummer 0 of 1
meegegeven
• De procedure enter_region wacht tot veilig het
kritieke gebied kan worden betreden.
• Als het proces klaar is met raadplegen of muteren
van gemeenschappelijke variabelen wordt de
procedure leave_region aangeroepen.
L.V. de Zeeuw
Computersystemen 2
37
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (13/15)
Proces 0 roept
enter_region aan
While
(0==0 and interested[1] ==TRUE)
Other is nu 1
interested[0] is TRUE
interested[1] is FALSE
Omdat proces 1 géén interesse toont
(interested[1] ==FALSE) wordt enter_region
meteen verlaten en mag proces 0 door naar
zijn kritieke gebied.
Indien beide processen vrijwel
gelijktijdig enter_region aanroepen zal
het proces dat als laatste turn wijzigt
moeten wachten.
L.V. de Zeeuw
Computersystemen 2
38
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (14/15)
De instructie TSL
TSL (TEST and SET LOCK) is een hardware oplossing voor
systemen met meerdere processoren.
Werking:
1. Inhoud geheugenwoord wordt gekopieerd naar een CPU
register.
2. Het geheugenwoord krijgt een waarde ≠ 0
De bewerkingen 1 en 2 zijn gegarandeerd ondeelbaar. Geen
enkele andere processor kan het geheugen benaderen
voordat de TSL instructie is afgerond.
L.V. de Zeeuw
Computersystemen 2
39
HOGESCHOOL ROTTERDAM / CMI
2.2.3Wederzijdse
uitsluiting
met busy waiting (15/15)
De instructie TSL
Flag coordineert de toegang tot
het gemeenschappelijk deel
van het geheugen
TSL:
•Flag wordt 1 gemaakt
•De oude waarde van flag staat
in het register
Essentieel is dat flag gedurende
deze bewerking niet gewijzigd
kan worden door een ander
proces
L.V. de Zeeuw
Computersystemen 2
40
HOGESCHOOL ROTTERDAM / CMI
2.2.4Sleep
and wakeup (1/8)
Het nadeel van de Peterson en TSL
oplossingen is ‘busy waiting’: het proces
wacht in een herhalingslus totdat hij zijn
kritische gebied mag betreden.
L.V. de Zeeuw
Computersystemen 2
41
HOGESCHOOL ROTTERDAM / CMI
2.2.4Sleep
and wakeup (2/8)
Nadelen ‘busy waiting’
• Verspilling CPU tijd
• Onverwachte effect:
Uitgangspunt
 Twee processen L met lage en H met hoge prioriteit.
 De regel van de scheduler is dat H wordt uitgevoerd als H in de
‘ready’ toestand is.
– Stel L zich op een bepaald moment in het zijn kritieke gebied.
– H komt in de ‘ready’ toestand en begint met ‘busy waiting’ voor
toegang to zijn kritieke gebied.
– L wordt niet door de scheduler aangewezen voor uitvoering en
komt daarom nooit meer uit zijn kritieke gebied …
L.V. de Zeeuw
Computersystemen 2
42
HOGESCHOOL ROTTERDAM / CMI
2.2.4Sleep
and wakeup (3/8)
Blokkeren van een proces als het proces niet is
toegestaan het kritieke gebied te betreden. Er
wordt nu géén CPU tijd verspilt.
System calls:
SLEEP blokkeert het proces dat deze call
aanroept.
WAKEUP(id) bevrijd proces id uit de
geblokkeerde toestand.
L.V. de Zeeuw
Computersystemen 2
43
HOGESCHOOL ROTTERDAM / CMI
2.2.4Sleep
and wakeup (4/8)
Hoe SLEEP en WAKEUP te gebruiken?
Voorbeeld:
Producent-consument (producer-consumer) of bounded
buffer probleem.
Twee processen delen een gemeenschappelijke buffer
(vaste omvang)
Het producent proces schrijft data in de buffer.
De consument proces haalt dat uit de buffer.
L.V. de Zeeuw
Computersystemen 2
44
HOGESCHOOL ROTTERDAM / CMI
2.2.4Sleep
and wakeup (5/8)
Het producent proces schrijft data in de buffer.
De consument proces haalt dat uit de buffer.
Als de buffer vol is:
• De producent moet blokkeren.
• De producent wordt door de consument uit de geblokkeerde
toestand gehaald wanneer de consument één of meer items uit
de buffer heeft gehaald.
Als de buffer leeg is:
• De consument moet blokkeren.
• De consument wordt door de producent uit de geblokkeerde
toestand gehaald wanneer de producent één of meer items in
de buffer heeft geplaatst.
L.V. de Zeeuw
Computersystemen 2
45
HOGESCHOOL ROTTERDAM / CMI
2.2.4Sleep
and wakeup (6/8)
• Producent-consument geeft aanleiding tot race condities.
• Count houdt het aantal items in de buffer bij (maximaal N).
• Zowel Producent als consument controleren het aantal items in
de buffer.
Producent:
• if (count==N) sleep();
• If (count==1) wakeup(consument)
Consument:
• if (count==0) sleep();
• If (count==N-1) wakeup(producent);
L.V. de Zeeuw
Computersystemen 2
46
HOGESCHOOL ROTTERDAM / CMI
2.2.4Sleep
and wakeup (7/8)
Race condities kunnen
ontstaan omdat de
benadering van count niet
aan beperkingen is gebonden.
Race condities kunnen
ontstaan omdat de
benadering van count niet
aan beperkingen is gebonden.
L.V. de Zeeuw
Computersystemen 2
47
HOGESCHOOL ROTTERDAM / CMI
2.2.4Sleep
and wakeup (8/8)
Race condities kunnen ontstaan omdat de benadering van count niet aan
beperkingen is gebonden.
Scenario voor race conditie
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Een lapmiddel zou zijn een bit wakeup waiting te
gebruiken dat kijkt naar wake-up signalen.
Bij een wakeup voor een niet geblokkeerd proces
wordt dit bit 1.
Later, als het wil overgaan naar geblokkeerde
toestand en wakeup waiting is 1 wordt het proces niet
geblokkeerd. wakeup waiting wordt 0 gemaakt.
Buffer leeg.
De consument leest count = 0.
Scheduler onderbreekt consument.
Scheduler start producent.
De producent plaats item in buffer.
Count wordt met 1 verhoogd. De waarde van count is nu 1.
De producent beredeneerd: count wás 0 dus consument is geblokkeerd.
De producent voert een wake-up uit op de consument. De consument was
logische gezien niet geblokkeerd! Het wakeup signaal gaat daarom verloren.
De scheduler start de consument en deze test de waarde van count die de
consument hiervoor reeds had gevonden. De consument vindt 0.
De consument wordt geblokkeerd.
De producent vult daarna de hele buffer.
De producent wordt geblokkeerd.
De consument en de producent blijven altijd geblokkeerd.
L.V. de Zeeuw
Computersystemen 2
48
HOGESCHOOL ROTTERDAM / CMI
2.2.5Semaforen
(1/8)
• E.W. Dijkstra introduceerde in 1965
de semafoor (seinpaal).
• Een nieuw type variabele.
• Als de semafoor nul is betekent dit
dat er geen wakeupsignalen zijn
bewaard.
• Als de semafoor positief is,
wachten één of meer wakeup
signalen op afhandeling.
Prof. dr. Edsger W. Dijkstra,
(1930-2002) Nederlands
belangrijkste informaticus
• EWD 74-1
L.V. de Zeeuw
Computersystemen 2
49
HOGESCHOOL ROTTERDAM / CMI
2.2.5Semaforen
•
(2/8)
De semafoor s kent twee
operaties: DOWN en UP
(In literatuur: PASSEER en VERHOOG,
WAIT en SIGNAL of SLEEP en
WAKEUP)
•
DOWN(s):
– als s=0 blokkeer proces
– als s>0 verminder s
proces gaat door.
•
UP(s): verhoog s
proces gaat door.
semafoor- of optische telegraaf
L.V. de Zeeuw
Computersystemen 2
50
HOGESCHOOL ROTTERDAM / CMI
2.2.5Semaforen
(3/8)
• Het controleren van de waarde,
• het veranderen van de waarde en
• het mogelijk blokkeren van het proces
één
L.V. de Zeeuw
wordt uitgevoerd als
atomaire actie
Computersystemen 2
51
HOGESCHOOL ROTTERDAM / CMI
2.2.5Semaforen
(4/8)
•
De UP en DOWN bewerkingen worden als systemcalls geïmplementeerd door
het interrupt mechanisme tijdelijk uit te zetten.
•
Bij meerdere CPU’s is de TSL (TEST and SET LOCK) instructie nodig zodat
maar één CPU tegelijk de semafoor kan benaderen.
•
UP(s) is dus niet het zelfde als s=s+1 !
Als twee processen A en B s=s+1 vrijwel tegelijk willen
uitvoeren kan het gebeuren dat voordat A de waarde
van s+1 aan s toekent B dezelfde som maakt. De
gewenste toename is dan verloren gegaan!
L.V. de Zeeuw
Computersystemen 2
52
HOGESCHOOL ROTTERDAM / CMI
2.2.5Semaforen
(5/8)
Iedere kritische sector wordt als volgt
geprogrammeerd:
DOWN(s);
kritische sector;
UP(s);
L.V. de Zeeuw
Computersystemen 2
53
HOGESCHOOL ROTTERDAM / CMI
2.2.5Semaforen
(6/8)
Oplossing producent-consument
(producer-consumer) of bounded buffer
probleem:
Programma voor proces A
.
.
DOWN(s);
voeg item toe aan buffer;
UP(s);
.
.
L.V. de Zeeuw
Programma voor proces B
.
.
DOWN(s);
verwijder item uit buffer;
UP(s);
.
.
Computersystemen 2
54
HOGESCHOOL ROTTERDAM / CMI
2.2.5Semaforen
(7/8)
Binaire semafoor
L.V. de Zeeuw
Computersystemen 2
55
HOGESCHOOL ROTTERDAM / CMI
2.2.5Semaforen
(8/8)
In stap 5 wordt de UP
uitgevoerd.
1.
2.
3.
4.
De afhandeling van Interrupts
kunnen worden
afgeschermd met semaforen.
5.
L.V. de Zeeuw
Computersystemen 2
Begin waarde van een I/O semafoor is 0
De I/O resource voert een DOWN uit op
bijbehorende semafoor.
Het I/O proces wordt geblokkeerd.
Zodra een interrupt wordt ontvangen wordt
een UP uitgevoerd op bijbehorende semafoor
(stap 5)
Het proces komt in de ready-toestand
56
HOGESCHOOL ROTTERDAM / CMI
2.2.6Event
counters (1/2)
Een oplossing voor producent-consument probleem kan
ook gebruik worden gemaakt van event counters die
géén wederzijdse uitsluiting vereisen.
Op event counters worden drie operaties gedefinieerd:
1.
2.
3.
Read(E):
Advance(E):
Await(E,v):
Geeft de huidige waarde van E
Verhoogd (ondeelbaar) de waarde van E met 1
Wacht tot E ten minste de waarde v heeft.
Event counters alleen maar toe.
L.V. de Zeeuw
Computersystemen 2
57
HOGESCHOOL ROTTERDAM / CMI
2.2.6 Event
counters
(2/2)
L.V. de Zeeuw
Computersystemen 2
58
HOGESCHOOL ROTTERDAM / CMI
2.2.7Monitoren
(1/6)
Wat kan er gebeuren als de
instructies down(&empty) en
down(&mutex) worden
omgekeerd?
down(&mutex)
down(&empty)
•
•
Als de buffer vol is wordt de producent
geblokkeerd
Mutex krijgt de waarde 0
•
•
•
De consument voert een down(&mutex) uit.
Mutex is al 0
De consument blokkeert ook.
L.V. de Zeeuw
Computersystemen 2
59
HOGESCHOOL ROTTERDAM / CMI
2.2.7Monitoren
(2/6)
Ondoordacht gebruik van semaforen leidt tot:
L.V. de Zeeuw
Computersystemen 2
60
HOGESCHOOL ROTTERDAM / CMI
2.2.7Monitoren
(3/6)
Om het programmeren eenvoudiger te maken kan een
monitor worden gebruikt als synchronisatie operatie
met een hoger abstractie niveau.
Monitor is een verzameling
• Procedures
• Variabelen
• Datastructuren
Processen kunnen een monitor aanroepen maar niet de
interne datastructuren van de monitor benaderen.
L.V. de Zeeuw
Computersystemen 2
61
HOGESCHOOL ROTTERDAM / CMI
2.2.7Monitoren
(4/6)
Monitor met de naam example
• Op ieder moment kan
maar één proces actief
zijn binnen de monitor.
• Een monitor is een
speciale constructie in
een programmeertaal.
L.V. de Zeeuw
Computersystemen 2
62
HOGESCHOOL ROTTERDAM / CMI
2.2.7Monitoren
(5/6)
Binnen een monitor zijn conditionele variabelen nodig om een
proces te blokkeren/de-blokkeren.
Op deze conditionele variabelen worden twee operaties
gedefinieerd:
• WAIT(variabele)
– het proces wordt geblokkeerd
– de toegang tot de monitor wordt vrijgegeven voor een ander proces
• SIGNAL(variabele)
– geeft het geblokkeerde proces vrij
– de monitor wordt door het huidige proces onmiddellijk verlaten
L.V. de Zeeuw
Computersystemen 2
63
HOGESCHOOL ROTTERDAM / CMI
2.2.7
Monitoren
(6/6)
De meeste
programmeertalen
kennen de
taalconstructie
monitor niet.
L.V. de Zeeuw
Computersystemen 2
64
HOGESCHOOL ROTTERDAM / CMI
2.2.8Mesage
passing (1/5)
Gegevens uitwisselen tussen machines:
• send (destination, &message)
• receive (source, &message)
L.V. de Zeeuw
Computersystemen 2
65
HOGESCHOOL ROTTERDAM / CMI
2.2.8Mesage
passing (2/5)
Ontwerpeisen voor systemen die gebruik
maken van message passing:
•
•
•
•
Ontvangstbevestiging,time out
Naamgeving processen: [email protected]
Verificatie, authenticatie
Zender en ontvanger op dezelfde machine
(efficiëntie)
L.V. de Zeeuw
Computersystemen 2
66
HOGESCHOOL ROTTERDAM / CMI
2.2.8Mesage
passing (3/5)
• Remote procedure call (RPC)
• Vanuit de cliënt lijkt een verzoek aan de server veel op het
aanroepen van een procedure.
• Daarna wordt er gewacht tot deze ‘procedure’ klaar is.
• Mooier is gebruik te maken van Remote Procedure Calls.
• De aanroepende en ontvangende procedures maken gebruikt
van een stub procedures die de communicatie tussen beide
machines afhandelt.
• Voor de aanroepende en ontvangende procedures lijkt alles
lokaal te worden afgehandeld.
L.V. de Zeeuw
Computersystemen 2
67
HOGESCHOOL ROTTERDAM / CMI
2.2.8Mesage
L.V. de Zeeuw
passing (4/5)
Computersystemen 2
68
HOGESCHOOL ROTTERDAM / CMI
2.2.8Mesage
passing (5/5)
Het producentconsumentprobleem
opgelost met
message passing
L.V. de Zeeuw
Computersystemen 2
69
HOGESCHOOL ROTTERDAM / CMI
2.2.9Gelijkwaardigheid
van de
basisoperaties (1/8)
De operaties
• Semaforen
• Event counters
• Monitoren
• Message passing
zijn in principe equivalent
L.V. de Zeeuw
Computersystemen 2
70
HOGESCHOOL ROTTERDAM / CMI
2.2.9Gelijkwaardigheid
van de
basisoperaties (2/8)
• Het implementeren van monitoren en message passing met
semaforen (hierna uitgewerkt)
• Implementeren van semaforen en message passing met
monitoren
• Implementeren van semaforen en monitoren met message
passing
NB Het gebruik van de basisoperatie ‘event counters’ voor het
implementeren van de andere basisoperaties wordt in het
leerboek verder niet besproken.
L.V. de Zeeuw
Computersystemen 2
71
HOGESCHOOL ROTTERDAM / CMI
2.2.9Gelijkwaardigheid
van de
basisoperaties (3/8)
Het implementeren van monitoren met semaforen
Te programmeren:
• Bij iedere monitor hoort een binaire semafoor mutex met
startwaarde 1
• Bij iedere conditionele variabele hoort een semafoor met
startwaarde 0
• Betreden monitor controleren met semafoor mutex
• Bij aanroep monitor procedure: DOWN(mutex)
– Als de monitor al wordt gebruikt dan wordt het proces geblokkeerd.
• Bij verlaten monitor procedure: UP(mutex)
– Een wachtend proces kan nu de monitor gebruiken.
L.V. de Zeeuw
Computersystemen 2
72
HOGESCHOOL ROTTERDAM / CMI
2.2.9Gelijkwaardigheid
van de
basisoperaties (4/8)
WAIT wordt uitgevoerd op conditionele variabele c.
Te programmeren:
• UP(mutex)
• DOWN(c)
• DOWN(mutex)
SIGNAL wordt uitgevoerd op conditionele variabele c.
Te programmeren:
• UP(c)
L.V. de Zeeuw
Computersystemen 2
73
HOGESCHOOL ROTTERDAM / CMI
2.2.9Gelijkwaardigheid
van de
basisoperaties (5/8)
Gevolg:
Zowel consumer als
producer actief in monitor,
maar …
Mutex garandeert
exclusieve toegang tot de
monitor
if count=1 signal(empty)
Consumer naar ready
toestand
Wordt uitgevoerd als:
•UP(mutex)
•DOWN(empty)
•DOWN(mutex)
Producer kan de
monitor betreden
Daarom wait(empty)
Consumer wordt
geblokkkeerd
Stel …
Consumer start eerst en
ontdekt dat er niets in de
buffer staat ..
… de schade blijft beperkt
om dat na het uitvoeren van
signal de monitor moet
worden verlaten.
(programmeerregel)
L.V. de Zeeuw
Computersystemen 2
74
HOGESCHOOL ROTTERDAM / CMI
2.2.9Gelijkwaardigheid
van de
basisoperaties (6/8)
Wat als …
Producent: UP(mutex)
voordat
Consument: DOWN(mutex) ?
•
•
•
•
De producent kan dan opnieuw de monitor betreden voordat de
consument de DOWN(mutex) heeft uitgevoerd.
Geen ongelukken omdat de consument géén gemeenschappelijke
gegevens kan raadplegen of muteren voordat de consument een
DOWN(mutex) heeft uitgevoerd.
Als de producent zich op dat moment in monitor bevindt is de waarde
van mutex 0.
De consument wordt geblokkeerd totdat de producent de monitor
verlaat met UP(mutex)
L.V. de Zeeuw
Computersystemen 2
75
HOGESCHOOL ROTTERDAM / CMI
2.2.9Gelijkwaardigheid
van de
basisoperaties (7/8)
Het
implementeren
van message
passing met
semaforen
L.V. de Zeeuw
Computersystemen 2
76
HOGESCHOOL ROTTERDAM / CMI
2.2.9Gelijkwaardigheid
van de
basisoperaties (8/8)
Zo verder … Zie leerboek.
• Implementeren van semaforen en message passing met
monitoren
• Implementeren van semaforen en monitoren met message
passing
L.V. de Zeeuw
Computersystemen 2
77
HOGESCHOOL ROTTERDAM / CMI
2.3Klassieke
problemen op het geboed van
communicatie tussen processen (1/1)
Het probleem
van de
etende filosofen
L.V. de Zeeuw
Het probleem
van de lezers
en schrijvers.
Computersystemen 2
78
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (1/13)
• Het probleem van de etende filosofen is door Dijkstra (1965)
bedacht en opgelost.
(dat zouden meer mensen moeten doen)
L.V. de Zeeuw
Computersystemen 2
79
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (2/13)
•
•
•
•
Vijf filosofen eten spaghetti.
De spaghetti is erg glibberig.
Je hebt twee vorken nodig.
Tussen de borden ligt steeds
één vork.
L.V. de Zeeuw
Computersystemen 2
80
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (3/13)
• Een filosoof doet
afwisselend twee dingen:
– hij eet of
– hij denkt
• Als hij honger heeft probeert
hij de linker én rechter vork
te gebruiken.
• De vorken worden in
willekeurige volgorde één
voor één gepakt.
L.V. de Zeeuw
Computersystemen 2
81
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (4/13)
• Als hij twee vorken te
pakken heeft kan hij enige
tijd eten
• Hierna worden de vorken
weer op tafel gelegd.
• Daarna denkt de filosoof
weer een tijdje.
L.V. de Zeeuw
Computersystemen 2
82
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (5/13)
Kun je een programma
schrijven voor iedere
filosoof?
• Het programma moet de
voorgaande beschrijving
uitvoeren.
• Het programma mag niet
vastlopen.
L.V. de Zeeuw
Computersystemen 2
83
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (6/13)
L.V. de Zeeuw
Computersystemen 2
84
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (7/13)
L.V. de Zeeuw
Computersystemen 2
85
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (8/13)
Als alle filosofen tegelijkertijd hun
linker vork pakken eet niemand meer.
L.V. de Zeeuw
Computersystemen 2
86
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (9/13)
Programma aanpassing:
• Claim linker vork
• Kijk of rechtervork
beschikbaar is
• Zo niet, leg dan de linker
vork weer neer.
• Wacht dan enige tijd en
probeer het opnieuw …
L.V. de Zeeuw
Computersystemen 2
87
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (10/13)
Programma aanpassing (1):
• Claim linker vork
• Kijk of rechtervork
beschikbaar is
• Zo niet, leg dan de linker
vork weer neer.
• Wacht dan enige tijd en
probeer het opnieuw …
L.V. de Zeeuw
Computersystemen 2
88
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (11/13)
Een willekeurige tijd wachten?
We willen een oplossing die altijd
tot een goed resultaat leidt en
niet kan vastlopen ten gevolge
van een onwaarschijnlijke serie
toevalsgetallen …
L.V. de Zeeuw
Computersystemen 2
89
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers (12/13)
Programma aanpassing (2):
DOWN(mutex)
UP(mutex)
Telkens kan slechts één filosoof
eten…
L.V. de Zeeuw
Computersystemen 2
90
HOGESCHOOL ROTTERDAM / CMI
2.3.1Het
probleem van de
dining philosophers
(13/13)
Programma
aanpassing (3):
L.V. de Zeeuw
Computersystemen 2
91
HOGESCHOOL ROTTERDAM / CMI
Edsger Wybe Dijkstra (1/1)
• Noorderlicht
documentaire
L.V. de Zeeuw
Computersystemen 2
92
HOGESCHOOL ROTTERDAM / CMI
Edsger Wybe Dijkstra (2/2)
Website van Dijkstra met links naar zijn EWD-tjes
L.V. de Zeeuw
Computersystemen 2
93
HOGESCHOOL ROTTERDAM / CMI
2.3.2
Het probleem van de readers
en writers (1/2)
Model voor de toegang tot een database
• Veel processen willen uit de DB lezen of
naar de DB schrijven.
• Als één proces naar de DB schrijft mag
geen enkel ander proces lezen of
schrijven.
L.V. de Zeeuw
Computersystemen 2
94
HOGESCHOOL ROTTERDAM / CMI
2.3.2
Het probleem van de readers
en writers (2/2)
De eerste reader krijgt toegang
tot de DB door een down(&db).
Elke volgende reader krijgen
toegang door rc = r+1
Als een reader klaar is met
lezen rc=rc-1
De laatste reader voert een
up(&db) uit.
Readers hebben hier een hogere
prioriteit dan writers.
Er zijn ook oplossingen voor het
omgekeerde
L.V. de Zeeuw
Computersystemen 2
95
HOGESCHOOL ROTTERDAM / CMI
2.4Proces
scheduling (1/3)
Als er meer dan één proces ready is neemt de
scheduler de beslissing welk proces eerst
wordt uitgevoerd.
L.V. de Zeeuw
Computersystemen 2
96
HOGESCHOOL ROTTERDAM / CMI
2.4Proces
scheduling (2/3)
Criteria voor een scheduling algoritme:
Eerlijkheid
Het proces krijgt een eerlijk deel van de CPU tijd
Efficiency
Zorgt dat de CPU 100% van de tijd bezig is
Responsetijd
Minimaliseren voor interactieve gebruikers
Doorlooptijd
Minimaliseren voor batch gebruikers
Bezettingsgraad
Zoveel mogelijk processen per tijdseenheid.
Deze criteria zijn vaak tegenstrijdig
L.V. de Zeeuw
Computersystemen 2
97
HOGESCHOOL ROTTERDAM / CMI
2.4Proces
scheduling (3/3)
Pre-emptive scheduling:
Processen die ‘running’ zijn worden
tijdelijk uitgesteld.
Run to completion:
(Batch) processen maken hun taak
geheel af.
L.V. de Zeeuw
Computersystemen 2
98
HOGESCHOOL ROTTERDAM / CMI
2.4.1Round
robin scheduling (1/2)
• Ieder proces krijgt een tijdsinterval (quantum)
toegewezen.
L.V. de Zeeuw
Computersystemen 2
99
HOGESCHOOL ROTTERDAM / CMI
2.4.1Round
robin scheduling (2/2)
Als het quantum …
• te kort is verminderd dit de efficientie
van de CPU
– Een process of context switch kost immers tijd
• te lang is geeft dit een slechte response
voor korte interactieve opdrachten
L.V. de Zeeuw
Computersystemen 2
100
HOGESCHOOL ROTTERDAM / CMI
2.4.2Scheduling
met
prioriteiten (1/2)
Niet alle processen zijn even belangrijk.
Priority scheduling:
• Aan processen wordt een prioriteit toegewezen.
• Een ready process met de hoogste prioriteit wordt uitgevoerd.
•
Toewijzen van prioriteiten kan statische of dynamische gebeuren.
– De prioriteit van een proces kan op basis van een interrupt worden verlaagd
om te voorkomen dat processen met de hoogste prioriteit voor onbepaalde
tijd worden uitgevoerd.
– I/O gebonden processen moeten vaak wachten en verbruikt al wachtend
zijn quantum. Als dat gebeurt kan daarna een dergelijk proces een hogere
prioriteit worden gegeven.
Bijvoorbeeld: Nieuwe prioriteit = quantum / gebruikte tijd
L.V. de Zeeuw
Computersystemen 2
101
HOGESCHOOL ROTTERDAM / CMI
2.4.2Scheduling
met
prioriteiten (2/2)
L.V. de Zeeuw
Computersystemen 2
102
HOGESCHOOL ROTTERDAM / CMI
2.4.3Meer
wachtrijen (1/1)
Het aantal proces wisselingen moet worden beperkt.
tegenover
Proces quanta moeten zo klein mogelijk worden gehouden.
Een oplossing is te gaan werken met prioriteitsklassen.
• Hoogste klasse: 1 quantum
• Op één na hoogste klasse: 2 quanta
• Op twee na hoogste klasse: 4 quanta
• Etc.
Als de toegewezen quanta zijn verbruikt wordt het proces in de eerst
volgend lagere prioriteitsklasse ingedeeld.
•
•
Kort lopende interactieve processen worden bevoordeeld.
Het aantal process wisselingen wordt beperkt
L.V. de Zeeuw
Computersystemen 2
103
HOGESCHOOL ROTTERDAM / CMI
2.4.4Shortest
job first (1/4)
• Voor jobs met een vooraf
bekende verwerkingstijd is de
gemiddelde doorlooptijd het
kleinst als wordt begonnen met
de korst durende job.
Gemiddelde doorlooptijd
(8+
8+4
8+4+4
8+4+4+4)
/4= 14
L.V. de Zeeuw
Gemiddelde doorlooptijd
(a+
a+b
a+b+c
a+b+c+d)
/4=(4a+3b+2c+d)/4
(a,b,c,d tijd nodig voor respectievelijk 1e,2e,3e,4e job)
Gemiddelde doorlooptijd
(4+
4+4
4+4+4
4+4+4+8)
/4=11
Computersystemen 2
104
HOGESCHOOL ROTTERDAM / CMI
2.4.4Shortest
job first (2/4)
• Het zou mooi zijn dit ook voor
interactieve processen te kunnen
gebruiken.
• Probleem is dat vooraf de
verwerkingstijd niet goed bekend is.
• Een schatting is te maken door te kijken
naar het historische gedrag van een
proces.
L.V. de Zeeuw
Computersystemen 2
105
HOGESCHOOL ROTTERDAM / CMI
2.4.4Shortest
job first (3/4)
• Verwerkingstijden voor
zekere terminal:
T0,T1,T2,T3, etc
• Bepaal het gewogen
gemiddelde waarbij de
weegfactor de invloed
van voorgaande
verwerkingstijden groter
of kleiner maakt.
L.V. de Zeeuw
Computersystemen 2
106
HOGESCHOOL ROTTERDAM / CMI
2.4.4Shortest
job first (4/4)
Verwerkingstijden voor zekere terminal:
T0,T1,T2,T3, etc
Aging is de techniek waarbij de volgende waarde van een reeks wordt
bepaald door het gewogen gemiddelde van de huidige meting en
voorgaande bepaling.
Kies: aT0+(1-a)T1 met a= ½ (shift 1 bit naar rechts)
Dan:
1e bepaling: T0
2e bepaling: ½ T0+(1- ½)T1 = ½ T0 + ½T1
3e bepaling: ½(½ T0 + ½T1)+(1-½)T2 = ¼ T0 + ¼ T1 + ½T2
4e bepaling: ½(¼ T0 + ¼ T1 + ½T2 )+(1-½)T3 = 1/8T0+1/8T1+ ¼ T2+½T3
L.V. de Zeeuw
Computersystemen 2
107
HOGESCHOOL ROTTERDAM / CMI
2.4.5Policy
driven scheduling (1/1)
• Doe een belofte en probeer die waar te maken.
• Voorbeeld:
Bij n gebruikers krijgt ieder 1/n deel van de CPU tijd.
• De gebruikte proces tijd wordt bijgehouden.
• De scheduler bepaalt voor elk proces:
gebruikte proces tijd / toegewezen tijd
en wijst eerst de processen aan de CPU toe met de
kleinste verhouding.
L.V. de Zeeuw
Computersystemen 2
108
HOGESCHOOL ROTTERDAM / CMI
2.4.6Scheduling
op
twee niveau’s (1/1)
Scheduler op het laagste
niveau maakt ‘ready’
processen in intern
geheugen ‘running’
Scheduler op het hoogste
niveau brengt ‘ready’
processen op disk naar
intern geheugen en
omgekeerd.
L.V. de Zeeuw
Computersystemen 2
109
HOGESCHOOL ROTTERDAM / CMI
Dit was het …
Huiswerk:
• Lees hoofdstuk 2
• Maak de opgaven
L.V. de Zeeuw
Computersystemen 2
111