1. No category

Notater til Teknik 1
Vidar Jon Bauge
Notater til Teknik
Vidar Jon Bauge
2005
Datamatikeruddannelsen efterår 2005
Side 1 af 54
Notater til Teknik 1
Vidar Jon Bauge
Indholdsfortegnelse
Operativsystemer........................................................................................................................
...............4
Batch systemer...........................................................................................................................
...........4
Time-sharing systemer.......................................................................................................................
...4
Computer Systemer............................................................................................................
.......................6
I/O struktur..............................................................................................................................................
...6
I/O interrupts.........................................................................................................................................
.....6
DMA struktur.....................................................................................................................................
........7
Storage struktur.......................................................................................................................................
...7
Main memory............................................................................................................................................
.8
Operativsystemers struktur...............................................................................................................
.........9
System komponenter...........................................................................................................
......................9
Proces styring...................................................................................................................................
.....9
Main memory management..............................................................................................................
.........9
File management....................................................................................................................................
..10
I/O system management......................................................................................................
....................10
Secondary storage management..............................................................................................
................10
Netværk............................................................................................................................................
........11
Protection system............................................................................................................................
.........11
Command interpreter system..............................................................................................................
.....11
Operativsystem services.....................................................................................................
.....................11
System kald.........................................................................................................................................
.....12
System programmer..............................................................................................................................
...13
System struktur........................................................................................................................
................14
Simple structure..................................................................................................................
................14
Layered approach..............................................................................................................................
..15
Microkernel....................................................................................................................................
.....15
Virtual machines......................................................................................................................
................15
Implementering.........................................................................................................................
..........15
Fordele........................................................................................................................
........................16
Java................................................................................................................................
..........................16
Processer.................................................................................................................................
.................17
Proces status............................................................................................................................................
.17
Proces Control Block (PCB)...........................................................................................
........................18
Process scheduling...............................................................................................................................
....18
Scheduling queues..........................................................................................................
....................19
Schedulers..............................................................................................................................
.............19
Context switch......................................................................................................................
...................20
Process creation....................................................................................................................
...................20
Process termination..................................................................................................................................
20
Cooperating processes..............................................................................................................
...............20
Tråde.................................................................................................................................
.......................22
Fordele........................................................................................................................
........................22
User og kernel tråde.....................................................................................................................
.......22
Tråde i Java.................................................................................................................................
.............24
Tråd behandling..............................................................................................................
....................24
En tråds tilstande...............................................................................................................................
..24
Datamatikeruddannelsen efterår 2005
Side 2 af 54
Notater til Teknik 1
Vidar Jon Bauge
Tråde i JVM.............................................................................................................................
................25
JVM og værtens operativsystem........................................................................................
.....................25
CPU Scheduling - Basic concepts................................................................................................
...........26
CPU-I/O burst cycle..........................................................................................................
......................26
CPU scheduler......................................................................................................................
...................26
Preemptive scheduling...........................................................................................................................
..26
Dispatcher................................................................................................................................
................26
Schedulerings alogritmer..................................................................................................................
.......27
First come, First-served.....................................................................................................
.................27
Shortest job first scheduling.............................................................................................
..................27
Priority Scheduling............................................................................................................
.................27
Round-Robin scheduling....................................................................................................
................27
Proces synkronisering.........................................................................................................................
.....28
Samarbejdende(Cooperating) processer........................................................................................
.....28
Producer - consumer ..............................................................................................................
............28
Kritisk område (Critical section)....................................................................................................
.........29
Semaforer...........................................................................................................................................
......29
Brug..................................................................................................................................................
...29
Deadlocks and starvation......................................................................................................................
...30
Dining philosopher..............................................................................................................
....................30
Fejl brug af semaforer.................................................................................................
............................31
Monitorer..............................................................................................................................
...................31
Java synkronisation..................................................................................................................................
35
Bounded Buffer.................................................................................................................................
..35
Deadlocks...................................................................................................................
.............................37
System model..................................................................................................................................
....37
Deadlock characterization...........................................................................................
.......................37
Betingelser der skal opfyldes.............................................................................................................
.37
Ressource allokerings graf....................................................................................
.............................38
Metoder til at håndtere deadlocks..........................................................................
............................38
Undgåelse af deadlocks.................................................................................................
.....................38
Forebyggelse af deadlocks....................................................................................
.............................38
Memory................................................................................................................................................
....39
Logisk/Fysisk adresse rum...........................................................................................
......................39
Paging.....................................................................................................................
............................40
Virtual memory..............................................................................................................................
..........42
Demand paging......................................................................................................................
.............42
Begreber...................................................................................................................................
...........42
Nødvendig hardware support..................................................................................
...........................43
Page replacement.................................................................................................................
...............43
Implementering.........................................................................................................................
..........44
Filsystemer..........................................................................................................................................
.....47
Filer....................................................................................................................................
.................47
Fil attributter..................................................................................................................
.....................47
Fil operationer..............................................................................................................................
.......47
Filtyper.....................................................................................................................................
...........48
Filstruktur.........................................................................................................................................
...49
Intern filstruktur.........................................................................................................................
.........49
Allokeringsmetoder.....................................................................................................
.......................49
Fortløbende (Contiguous) allokering...........................................................................
......................49
Datamatikeruddannelsen efterår 2005
Side 3 af 54
Notater til Teknik 1
Vidar Jon Bauge
Lenket allokering.................................................................................................................
...............51
Indekseret allokering................................................................................................
..........................51
Performance.........................................................................................................................
...............52
I/O systemer.....................................................................................................................................
........53
I/O operationer..........................................................................................................................
..........53
Polling..................................................................................................................................
...............54
Interrupts................................................................................................................................
.............54
Direct memory access...................................................................................................................
......56
Programmed IO (PIO)...................................................................................................
.....................56
DMA.............................................................................................................................
......................57
Datamatikeruddannelsen efterår 2005
Side 4 af 54
Notater til Teknik 1
Vidar Jon Bauge
Operativsystemer
Operativsystemet er et program der optræder som mellemled mellem hardware og brugeren.
Operativsystemet sætter brugeren i stand til at køre programmer og derved udnytte computeren, eller
hardwaren. Det primære mål for operativsystemet er at gøre computeren nem at bruge, og sørge for
effektiv udnyttelse af hardwaren.
Et computersystem kan groft indeles i 4:
•
Hardware
•
Operativsystemet
•
Applikationsprogrammer
•
Brugere
Operativsystemet kontrollerer og koordinerer brugere og applikationers brug af hardwareressourcer.
Operativsystemer og arkiktektur har haft stor indflydelse på hinanden, og design af begge dele har
påvirket hinanden. En vigtig faktor for design af operativsystemer er forventet brug af systemet.
Batch systemer
De første computere hadde en stor fysisk størrelse, der blev kørt fra en konsol. Almindelige input
enheder var kortlæsere og båndstationer. Almindelige output enheder var linieskrivere, båndstationer
og kort. Brugeren afleverede en job med program, data og kontroldata, i form af hulkort, til
operatøren der kørte den og sendte resultatet tilbage til brugeren.
Operatørens opgave var at overføre kontrollen fra den ene job til den næste. For at øge udnyttelsen af
maskinen, blev jobbene sorteret i batches efter hvilke behov de havde.
På denne måden var CPU'en ofte ledig, da hastigheden på de mekaniske input enheder ikke står i
forhold til CPU'ens regnehastighed.
Med indførelsen af diske, kunde man samle flere jobber på en disk. Med direkte access til flere jobs
var det mulig at indføre job scheduling der gav bedre udnyttelse af hardware.
Det vigtigste apekt ved job scheduling er multiprogramming, så CPU'en kan køre en anden job mens
den første f.eks venter på en I/O operation.
Time-sharing systemer
Time-sharing eller multitasking er en naturlig forlængelse af job-scheduling. Med time-sharing
menes det at CPU'en skifter mellem flere samtidige jobs så hurtig at brugeren kan interagere med de
forskellige programmer samtidig mens de kører.
Et time-sharing system tillader mange samtidige brugere på en computer. Siden en kommando eller
action ofte er hurtig, behøves der ikke meget CPU tid for hver bruger. Eftersom CPU'en skifter hurtig
fra den ene bruger til den næste, fremstår systemet som værende helt til disposition for den enkelte
bruger.
Et time-sharing system bruger CPU scheduling og multiprogramming for at tildele hver bruger
ressourcer. Hver bruger har mindst et program i RAM.
Time-sharing systemer er som regel mere komplicerede end multiprogramming systemer. Begge må
have flere jobber i RAM samtidig. Derfor må de have memory management og protection.
For at holde en acceptabel response tid, må processer kunde flyttes ind og ud fra main memory, så
Datamatikeruddannelsen efterår 2005
Side 5 af 54
Notater til Teknik 1
Vidar Jon Bauge
disken bliver er sekundær opbevaringsplads – virtual memory. En oplagt fordel ved dette er at
programmer kan være større end tilgængelig memory.
En anden måde at løse dette på, er ved at starte en process uden at overføre hele programmet til
memory.
Time-sharing systemer må også have et filsystem, og derved adgang til diske.
Dessuden kræver time-sharing systemer at processer kan køre samtidig, hvilket stiller krav om et
system for CPU scheduling.
Datamatikeruddannelsen efterår 2005
Side 6 af 54
Notater til Teknik 1
Vidar Jon Bauge
Computer Systemer
Et computersystem består af en CPU og en række device controllere der er koblet sammen med en
bus der giver adgang til delt minde (RAM).
Hver device controller styrer en speciel enhed på systemet, f.eks diske, grafikkort, lydenheder osv
CPU'en og device controllerne kan køre samtidig, og dermed konkurrere om memory. For at sikre delt
adgang, er systemet udstyrt med en memory controller der kontrollerer adgang til memory.
Ved opstart overlades kontrollen af systemet til et lille initialiseringsprogram, bootstrap. Dette
programmet må vide hvordan systemets kerne loades og startes. Operativsystemet starter den første
proces, og venter på at en hændelse skal optræde. Optrædelsen af en hændelse viser sig som regel som
en interrupt, udløst enten af en input enhed (hardware interrupt) eller af et kørende program
(software interrupt).
Mange typer hændelser kan udløse en interrupt, som f.eks en I/O operation er f'ærdig, division med
nul, ugyldig minne acces eller anmodning om en operation fra operativsystemet. For hver interrupt er
der en rutine der håndterer den.
Når CPU'en modtager en interrupt, standser den udførelsen af den proces der kører, og overlader
kontrollen til en service rutine for den indkomne interrupt. Når denne er udført fortsætter kørselen af
den proces der blev afbrudt.
Interrupts er en central del i moderne operativsystemer. De rutiner der køres når systemet modtager en
interrupt, ligger som regel på en lav memory adresse. Systemet har en interrupt vector der er en tabel
med pegere til de forskellige rutinerne.
Moderne systemer er interrupt driven hvilket vil sige at når systemet er færdig med de opgaver det
har, vil det begynde at vente på at noget skal ske der udløser en interrupt. F.eks at brugeren flytter
musen eller trykker på tastaturet.
I/O struktur
En device controller for en diskenhed har en buffer der er afhængig af det device den kontrollerer, og
er vanligvis på størrelse med diskens mindste adresserbare størrelse – en sektor.
I/O interrupts
For at starte en I/O operation, loader CPU'en de nødvendige registre i device controlleren. Device
controlleren undersøger så indholdet i disse registrene for at finde ud hvad den skal – om den skal
læse eller skrive. Hvis der skal læses, begynder controlleren at fylde sin buffer. Når dette er færdig,
sender den en interrupt, der informerer CPU'en om at den er klar.
Når systemet modtager er I/O interrupt, er det som regel efter anmodning fra en bruger process.
Behandlingen af denne interrupt kan ske på 2 måder:
•
Synchronous I/O
I/O operationen startes, når den er færdig tilbageføres kontrollen til brugerprocessen
•
Asynchronous I/O
Kontrollen returneres til brugerprocessen før I/O operationen er færdig og I/O operationen
Datamatikeruddannelsen efterår 2005
Side 7 af 54
Notater til Teknik 1
Vidar Jon Bauge
fortsætter mens systemet arbejder med andre ting.
Synchronous I/O forhindrer at flere I/O operationer kan køre samtidig på flere devices, og udelukker
kørsel af andre processer mens systemet venter på en I/O operation.
Derfor er det bedre at I/O operationen starter, og så køre bruger- eller operativsystem kode. Hvis
ingen bruger- eller system processer venter på at blive kørt, kan systemet gå over i en wait tilstand.
Dette betyder at systemet må kunne håndtere mange samtidige interrupts. Til dette formålet har
operativsystemet en device-status table. Hver opføring i tabellen indikerer en devices type, adresse
og status. Eftersom det er mulig for flere processer at anmode om en bestemt device, er der også en
wait queue for hver I/O device.
En I/O enhed sender et interrupt når det trenger service. Operativsystemet bestemmer så hvilken enhe
der har sendt en interrupt og slår opp i device-status table for at bestemme dens status og oppdaterer
tabellen i forhold til det indkomne interrupt. Hvis andre processer ligger i kø til den samme enhed,
gives en af disse adgang til enheden. Hvis en process ventede på at I/O operationen skulle blive
færdig, kan denne processen nu fortsætte, hvis ikke fortsætter en af de andre processerne der er i kø.
Den største fordelen ved asynchronous I/O er øget effeltivitet. Mens en I/O operation udføres, kan
systemet udføre andre processer eller starte andre I/O operationer.
DMA struktur
Devices controllere der håndterer langsomme medier, kan ikke levere data hurtig nok til at holde
CPU'en aktiv med en datastrøm. Dette hånderes ved hjælp af asynchronous I/O der tillader andre
processer at køre parallelt med en I/O operation.
Hurtige enheder, som båndstationer eller netværksenheder, kan levere datastrømme op imod memorys
hastighed. Dermed ville interrupts komme så ofte at der ikke bliver CPU tid til andre processer. For at
løse dette problemet bruges direct memory access for hurtige I/O enheder. Efter at have sat pegere,
buffere og tællere for enheden kan device controlleren overføre blokke med data direkte til memory
uden CPU tid. Der generes kun en interrupt pr blok i stedet for en interrupt pr byte som ved
langsomme enheder.
CPU'ens opgaver er grundlæggende de samme. En proces anmoder om en enhed. En device driver
setter DMA controllerens registre så den bruger den rigtige kilde- og destinationsadresse. DMA
controlleren starter så I/O operationen, og CPU'en er ledig til andre opgaver. Eftersom der bare kan
skrives en byte om gangen til RAM, stjæler DMA kontrolleren RAM cycler fra CPU'en. DMA
controlleren sender et interrupt når operationen er fuldført.
Storage struktur
Programmer må være i RAM for at blive udført. Memory er det eneste store medie CPU'en har
direkte adgang til. RAM implementeres som Dynamic Random Access Memory (DRAM) som en
række memory words eller bytes. Hver byte har sin egen adresse. Skrivning og læsning gennemføres
ved hjælp af load og store instruktioner til bestemte adresser. Load henter en speciell adresse til en af
CPU'ens registre, mens store flytter indholdet i et register til en angivet memory adresse.
En typisk instruktion-eksekution cyclus på et system med Von Neuman arkitektur indebærere en
fetch-decode-execute. Instruktionen hentes ind i CPU'ens instruktionsregister, instruktionen decodes
og kan forårsage at parametre hentes ind fra RAM til andre registre i CPU'en. Efter udførelse af
instruktionen kan data blive skrevet ”tilbage” til RAM.
Ideelt set, var programmer permanent opbevaret i RAM. Dette er imidlertid ikke muligt, da RAM er
Datamatikeruddannelsen efterår 2005
Side 8 af 54
Notater til Teknik 1
Vidar Jon Bauge
et volatilt medie der tømmes når der slukkes for systemet og fordi at RAM som regel ikke er stor nok
til at opbevare alle programmerne.
Derfor har alle systemer et sekundært medie i form af magnetiske diske hvor programmer og data
opbevares og læses ind i RAM når de skal bruges.
Andre medier til opbevaring af programmer og data er cdrom, cache memory, bånd etc. Hvert medie
holder program og data, der kan hentes ind i RAM når de skal bruges. Den vigtigste forskellen er
hastighed, pris, størrelse og mulighed for sletning/endring af de gemte data.
Main memory
CPU'ens egne registre og main memory er de eneste medier CPU'en har direkte adgang til. Der findes
instrukser der tager memory adresser som parametre, men ingen instrukser der tager disk adresser.
Dette betyder at data skal læses fra disken til memory for CPU'en kan få adgang til dem.
For at tillade lettere adgang til I/O enheder anvender mange computersystemer memory-mapped
I/O. I dette tilfælde knyttes områder i memory til device registre. Skrivning og læsning fra enheder
forårsager flytning af data til og fra disse registrene. Memory mapping egner sig for bl.a. hurtige
enheder, serie og parallelporten. CPU'en overfører data til og fra enheder ved at skrive til nogle få
registre, der kaldes I/O porte. For at sende en datastrøm til en enhed, kan CPU'en bare overføre en
byte til det aktuelle register. Enheden tømmer så registeret, og sætter et flag i device controlleren der
informerer om at enheden er klar til at modtage mer. Denne processen gentages såtil datastrømmen er
slut. Hvis CPU'en continuerlig checker kontrol bit'en for at se om enheden er ledig, taler man om
programmed IO. Hvis enheden derimod sender en interrupt når den er klar, er data overføringen
interrupt driven.
Registrene er som regel tilgængelige på en CPU cyklus og de fleste CPU'er kan udføre en eller flere
simple instruktioner på en cyklus. Dette gælder imidlertid ikke RAM. For at hindre at CPU'en står
inaktiv mens den venter på læsning fra RAM bruges en cache af hurtigere RAM mellem CPU'en og
main memory.
Datamatikeruddannelsen efterår 2005
Side 9 af 54
Notater til Teknik 1
Vidar Jon Bauge
Operativsystemers struktur
Operativsystemet fremskaffer et miljø hvordan man kan køre sine programmer. Designet av de
forskellige operativsystemer er imidlertid forskellig. Det at designe et operativsystem er en stor
opgave der må tage udgangspunkt i hvilke opgaver operativsystemet skal løse.
System komponenter
Byggingen af et operativsystem kan kun ske ved at dele det op i mindre, velafgrænsede opgaver eller
dele med nøje definerede funktioner, input og output.
Proces styring
Et program er i sig selv en passiv størrelse, og kan ikke gøre noget med mindre det læses over i
memory og udføres af CPU'en. En process kan defineres bl.a. som et kørende program med en
program counter udførelsen af en proces sker sekventielt en instruktion ad gangen. Systemopgaver,
som f.eks at sende et dokument til printeren eller håndtere I/O, er også processer. En proces kan
betragtes som en arbejdsenhed i systemet. Systemet består af mange processer, hvoraf nogen er
systemprocesser mens andre er brugerprocesser.
En proces trenger visse ressourcer, memory, CPU tid, filer, I/O enheder etc. Disse ressourcerne gives
enten ved opstart eller bliver allokeret under kørsel med parametre, f.eks. filnavn ved en filoperation.
Ressourcerne tilbageføres til systemet når processen afsluttes.
Operativsystem har følgende ansvar for afviklingen af processer:
•
Skabe og slette processer
•
Suspendere og genstarte processer
•
Metode for proces synkronisering
•
Metode for proces kommunikation
•
Metode for håndtering af deadlocks
Main memory management
Memoryens struktur består af en lang række adresser der kan skives og læses fra. Memory er den
eneste lagringsplads CPU'en har direkte adgang til. CPU'en henter instruktioner herfra og udfører dem
(fetch-decode-execute). Hvis CPU'en skal behandle data der ligger på disken, må de først læses over i
memory. For at bedre udnyttelsen af CPU'en og reducere responstid, må der ligge flere programmer i
memory samtidig. Der findes mange algoritmer for memory behandling, de alle har sine stærke og
svage sider. Valget af memory management er bl.a. harware bestemt da de forskellige algoritmerne
kræver sin egen hardware understøttelse.
Operativsystemet er ansvarlig for følgende i forbindelse med memory behandling:
•
Kontrol over hvilke dele av memory der er i brug og af hvem
•
Bestemme hvilke processer der skal læses ind i memory når der bliver ledig plads.
•
Allokere og Deallokere memory efter behov.
Datamatikeruddannelsen efterår 2005
Side 10 af 54
Notater til Teknik 1
Vidar Jon Bauge
File management
Filer kan gemmes på mange forskellige typer medier med hver sine egne karakteristika.
Operativsystemet fremskaffer et ens grænsesnit til disse forskellige enheder ved at abstrahere fra disse
karakteristika og skabe logiske lagringsenheder. Disse kan så tilgås ved hjælp af system kald.
En fil er en samling af data defineret af den der har oprettet filen. Filer kan representere både
programmer og data. De kan være formatteret til at opfylde et specielt formål elle ikke formateret i
det hele taget, som f.eks. en tekstfil. Filbegrebet er et meget abstrakt begreb.
Operativsystemet implementerer dette abstrakte begrebet ved at implementere de enheder der gemmer
filerne. I tillæg har operativsystemet kontrol med hvem der ejer og har adgang til den enkelte fil.
Operativsystemet har følgende ansvar for filbehandling:
•
Oprette og slette filer
•
Oprette og slette mapper
•
Understøtte metoder for at manipulere filer og mapper.
•
Flytte filer til sekundære lagringsenheder
•
Backups af filer til non-volatile medier
I/O system management
Et af formålene ved et operativsystem er at skjule de enkelt hardware enheder for brugeren. I Unix er
der et I/O subsystem der håndterer alle I/O enhder og som består af memory behandling der
inkluderer buffering, caching og spooling, en generell device driver interface og drivere for en enkelte
hardware enhed.
Secondary storage management
Programmer og data må befinde sig i memory for at CPU'en skal kunde eksekvere dem. Der er
imidlertid ikke plads nok i memory til at opbevare alle programmer og data. Dessuden slettes
indholdet i memory når der slukkes for systemet. Derfor opbevares programmer og data permanent på
secondary storage i form af en harddisk eller andet media. Da sekundær lagringsplads bruges ofte er
det vigtig at behandlingen af disse er så effektiv som mulig. Der findes forskellige algoritmer der kan
håndtere dette.
Operativsystemet sørger for følgende i forbindelse med sekundære medier:'
•
Behandling af ledig plads
•
Allokering af plads
•
Disk schedulering
Datamatikeruddannelsen efterår 2005
Side 11 af 54
Notater til Teknik 1
Vidar Jon Bauge
Netværk
Et distribueret system er et system med mange processorer der ikke deler memory, devices eller
klokke. Hver processor har sin egen memory og systemklokke og de kommunikerer over netværk
eller hurtige busser. Processorene i et distribueret system kan variere fra små mikrocomputere til store
computere. Et distribueret system kan få fysiske separerte og forskellige systemer til at fremst samlet
for brugeren der kan udnytte de ressourcer der findes i netværket. Operativsystemer behandler
vanligvis netværksadgang som en slags fil adgang hvor detaljerne omkring netværket er gemt i
enheder. Protokoller for distribuerede systemer er ftp, www, http etc
Protection system
Hvis et system understøtter flere brugere og flere samtidige processer er det nødvendig at beskytte
disse for hverandre. Til dette formaålet har operativsystemet mekanismer der sørger for at filer,
memory områder, CPU og andre ressourcer bare kan benyttes af en om gangen. Memory
adresseringshardware sørger for at hver process får tildelt sit område i memory, timeren sørger for at
hvis en proces får tildelt CPU tid, bliver den nødt til at afgive kontrol.
Protection er enhver mekanisme der kontrollerer adgangen for processer og brugere til de ressourcer
der er sat af til dem. Et system med fokus på sikkerhed, kan skelne mellem autoriseret og ikke
autoriseret brug af systemet.
Command interpreter system
Et vigtig systemprogram for mange operativsystemer er kommandofortolkeren eller shell. Dette
modtager og udfører systemkommandoer. Nogle operativsystemer har shelled indebyget i kernen,
mens andre har det som et eget program – UNIX og MS-Dos.
Nogle operativsystemer starter op i shellet ved opstart, mens andre, som Windows og MacOs starter
op i et grafisk miljø.
Operativsystem services
Akmindelige typer services som operativsystemet yder:
•
Kørsel af programmer
•
I/O operationer
•
Manipulation af filsystem
•
Kommunikation
•
Fejl håndtering
Funktioner til et operativsystem som sikrer effektiv drift af systemet
•
Ressource allokering
•
Logning, overvågning af ressource forbrug
•
Sikkerhed
Datamatikeruddannelsen efterår 2005
Side 12 af 54
Notater til Teknik 1
Vidar Jon Bauge
System kald
System kald giver en interface mellem processer og operativsystemet. Systemkald er som regel
tilgængelige i form af assembler instruktioner, og findes i manualer for assembler programmering.
Nogle systemer tillader system kald direkte fra høj niveau sprog, hvor de fremstår som funktions eller
subrutine kald. Nogle pogrammeringssprog, som C, C++ og Perl, er designet for at erstatte assembler
for system programmering. På Unix systemer kan systemkald udføres direkte fra et C eller C++
program. Under Windows er systemkald en del af Win32 API der er tilgængelig for alle acompilere
der er skrevet for MS Windows.
Java tillader ikke direkte systemkald fordi det kører ovenpå en Java Virtual Machine. Hvis et Java
program har behov for et systemkald gøres dette via JVM, derer designet for de forskellige systemer
og udfører system kald i henhold til disse. Systemkald er under java er implementeret i rutiner skrevet
i C, og kaldes derfor for native methods.
Systemkald kan groft deles op i 5 kategorier:
1. Proces kontrol
•
end, abort
Programmer må kunde afsluttes, enten normal(end) eller som resultat af en fejl(abort), og i så
tilfælde sende en fejlmeddelse eller memory dump
•
load, execute
En kørende proces kan have behov for at hente (load) og eksekvere (execute) en anden proces.
•
create, terminate proces
Disse processerne kan så fortsætte parallelt, mange systemer har et specielt kald for dette
(create process). Eller man har behov for at afslutte en proces der f.eks er blevet unødvendig
(terminate proces)
•
get/set proces attributter
Man skal kunde ændre på en proces' egenskaber under kørsel, f.eks. ændre dens prioritet eller
maksimalt tilladte kørselstid
•
wait
Sætte en process i venteposition
•
wait event, signal event
Sætte en process i venteposition mens den venter på at noget skal indtræffe, f.eks. en I/O
operation, eller vente på et signal om at det den venter på er indtruffet
•
alloker og frigiv memory
2. Fil manipulation
•
create/delete fil
•
open, close
•
read, write, reposition
Datamatikeruddannelsen efterår 2005
Side 13 af 54
Notater til Teknik 1
•
Vidar Jon Bauge
get/set fil attributter
3. Enhedsbehandling
•
anmod om/frigiv enhed
Hvis en proces har behov for en I/O enhed, må den først anmode om den (request), og når den
er ferdig skal den så frgigives igen så andre kan bruge den (release)
•
read, write, reposition
Når enheden så er allokeret, kan processen skrive (write), læse (read) og muligvis også
repositionere enheden
•
get/set enheds attributter
•
monter/afmonter enhed
4. Vedligeholdelse af information
Mange systemkald findes udelukkende for at overføre information mellem bruger programmer og
operativsystemet. De fleste operativsystemer har kald for at få tid og dato. Ellers kan dette dreje sig
om kald der returnerer ledig diskplads, antal brugere, operativsystemets version.
•
get/set tid og dato
•
get/set system data
5. Kommunikation
Der findes to modeller for kommunikation mellem processer. Message-passing model og sharedmemory model.
Ved meesage passing foregår kommunikation mellem processer ved at den ene proces sender en
melding via kernen til den anden proces.
Shared memory model går ud på at to eller flere processer har et fælles område i memory de begge
kan skrive og læse til.
Message passing er egnet til få og korte bekeder. Shared memory er sværere at implementere fordi
det kræver en synchronisering af det mindeområdet der er fælles. Dessuden skal man sikre sig at
processerne virkelig deler det samme område Begge metoderne er almindeligt brugt, og nogle
operativsystemer bruger begge metoder.
•
opret, slet kommunikationsforbindelse
•
send, modtag meldinger
•
overfør status information
•
koble fra/til enheder
System programmer
Til de fleste operativsystemer kommer der en række systemprogrammer
•
Filbehandling
Programmer til at oprette, slette, kopiere, omdøbe, printe, liste, og manipulere filer og mapper.
Datamatikeruddannelsen efterår 2005
Side 14 af 54
Notater til Teknik 1
•
Vidar Jon Bauge
Status information
Programmer til at hente data om systemet, som ledig dato, tid, diskplads, antal brugere, kørende
processer etc og formattere dem og vise dem i en læsbar form.
•
Ændring af filer
Tekst editorer til ændring af filer
•
Understøttelse af programmeringssprog'
Compilere og assemblere for en række programmeingsprog. For nogle systemer skal dette købes
separat.
•
Load og eksekver programmer
Absolute loaders, relocatable loaders, linkage editors, og overlay loaders samt debbugging
software.
•
Kommunikation
Programmer som sørger for virtuelle forbindelser mellem processer, brugere, og andre computer
systemer. De tillader brugere at sende meldinger til hinanden, til at gå på internettet, sende e-mails,
logge ind på en fjern computer eller overføre filer fra en maskine til en anden.
I tillæg til disse kommer bruger applikationer.
En vigtig del av et operativsystem er kommando fortolkeren der modtager en kommando fra brugeren
og udfører den. Nogle kommandofortolkere, som MS Dos comman.com har alle kommandoerne
indebygget, mens andre, som UNIX, bare tager en kommando med parametre og kører et selvstændigt
program. Dette gør den nem at udvide, man lægger bare et program i en folde hvor fortolkeren kan
finde den. Ulempen kan være at syntax er op til den enkelte programmør, noget der kan gøre systemet
inkonsistent. Fordelen ved at implementere kommandoerne inde i kommandofortolkeren er så at man
sikrer en enhetlig syntaks for hver kommando og at det går hutigere. Ulempen er så at det er sværere
at udvide den.
Operativsystemet, er fra brugerens synspunkt heller definert udfra system programmer og interface
end systemkald. Et system med MS Windows og MS-Dos har et vidt forskellig bruger interface men
benytter det samme sæt systemkald. Systemkaldene ser imidlertid anderledes ud, og brugeren ”føres
væk” fra de oprindelige systemkald.
System struktur
Et avanceret system som et moderne operativsystem må designes med omtanke for at fungere godt og
kunde modificeres på en simpel måde. En almindelig måde at gøre dette på er ved at dele opgaven op
i mindre deler heller end at have et stort monolitisk system.
Simple structure
Nogle systemer har ikke en vel afgrænset lagdeling i sin struktur. Dette gælder ofte systemer der
startede som små systemer til begrænset hardware, og blev udvidet efterhånden som harwaren blev
kraftigere.
I MS-Dos er interfaces og de forskellige lag ikke godt afgrænset. Applikationsprogrammer har direkte
adgang til grundlæggende I/O rutiner for skrivning til display og disk drev. Dette gør MS-Dos sårbar
overfor dårlig skrevne programmer, men var et nødvendig kompromis for at give maksimal
funktionalitet på begrænset hardware (Intel 8088)
Datamatikeruddannelsen efterår 2005
Side 15 af 54
Notater til Teknik 1
Vidar Jon Bauge
Det oprindelige UNIX har også lignende problemer. Det består af to separate dele, kernen og system
programmerne. Kernen er yderligere opdelt i en række interfaces og enhedsdrivere der er blevet lagt
til i årenes løb for at understøtte ny hardware. Dette har ført til at en stor mængde funktionalitet er
blevet lagt i et lag – kernen.
Layered approach
Indelingen af et system kan gøres på mange måder, og en af dem er lagdeling. Systemkomponenterne
implementeres som lag der lægges ovenpå hinanden. Debugging sker fra bunden, hvor man kan gå ud
fra at hardware er i orden. Dette indebærer at man altid kan lokalisere fejl, fordi laget under er
debugget og fejlfrit. Den største vanskelighed ved lagdeling er en rigtig in deling i lag. Eftersom et lag
kun har adgang til laget under er nøje planlægning vigtig. F. eks. driveren for diske må ligge lavere
end memory management, da memory management bruger diskene som virtuel memory.
Et andet problem med lagdeling er effektivivitet. Meldinger skal sendes mellem lagene og for hvert
lag skal måske parametre ændres, noget der kan føre til et mindre effektivt system
Microkernel
Efterhånden som UNIX kernen voksede sig stor i løbet af 80-årene, blev der udviklet en
modulariseret mikro kerne (Mach kernel). Alle mindre vigtige komponenter separeret fra kernen og
blev implementeret som system og bruger programmer. Mikro kernens vigtigste funktion er at skabe
kommunikation mellem klient programmerne og de andre services der kører i user space.
Communication sker ved message passing. Hvis f.eks et klient program vil have adgang til en fil, må
det henvende sig til filserveren. Dette sker aldrig direkte, men via kernen.
Fordelen med dette er at det er nemt at udbygge systemet, og ændringer i kernen bliver ændringerne
mindre fordi at kernen er lille. Mikro kernen giver også en højere sikkerhed da de fleste services kører
som bruger- istedenfor som kerne processer. Hvis en service svigter, kan resten af systemet køre
videre
Virtual machines
Begrebsmæssig er en computer bygget op lag, hvor hardware er det nederste lag. Derover ligger
kernen der bruger hardware instruktioner til at lave et sæt med systemkald. Programmer kan enten
henvende sig til hardware i form af systemkald eller harwareinstruktioner. På nogen systemer er
denne lagdeling ført ril det næste logiske skridt, nemlig virtual machines.
Ved at bruge CPU scheduling og virtuelt minde kan man det til at se ud som om hver proces har sin
egen processor med sin egen (virtuelle) memory (IBM VM operativsystem). Den fysiske computer
deler ressourcer ud på hver VM, CPU tid deles, og filsystmet skaber adgang til virtuelle printere etc.
En vanskelighed ved design af et sådant system er fordeling af diskplads. Dette løses ved at operere
med en minidisk for hver bruger ved at allokere diskplads til hver minidisk efter behov.
Implementering
Når VM skal implementeres, må der lægges meget arbejde i at sikre at der laves en nøjaktig kopi af
den underliggende maskine. VM kan køre i to modus, user mode og monitor mode. Programmer kan
kun udføres i user mode. En vsenetlig faktor er tid. En I/O operation kan tage længre eller kortere tid.
Hvis informationen der skal flyttes er spool'et bruges der meget kort tid på I/O operationer. Hvis dette
ikke er tilfælde tager I/O operationer længre tid, fordi VM skal kommunikere med hardware gennem
Datamatikeruddannelsen efterår 2005
Side 16 af 54
Notater til Teknik 1
Vidar Jon Bauge
mange led.
Hvis CPU'en skal servicere mange samtidige VM, kan systemet blive meget langsommere hvis alle
instruktionerne skal simuleres for at skabe ægte virtual machines.
Fordele
Et system med Wm har flere fordele. Hver virtuel maskine kører fuldstendig separat, noget der
eliminerer sikkerhedsproblemer. På den anden side er der heller ingen kommunikation. Dette løses
ved at flere VM kan deles om en minidisk. Dessuden er det mulig at sætte op et virtuelt netværk
mellem de virtuelle maskinerne. Vedligehold på systemet kan udøres på en virtuel maskine, noget der
giver meget lidt afbrud i driften pga vedligehold.
Virtual machines bruges i dag for at løse problemer med kompabilitet. Man kan f.eks lave en MS-Dos
virtual machine så man kan køre dos programmer under helt andre operativsystemer på en heæt anden
arkiktektur end dos er skrevet til (i386).
Java
Java består af tre grundlæggende komponenter
1. Programming language specifikation
Java kan bedst beskrives som et objektorienteret, ikke afhængig af arkitektur, distribueret og multi
trådet programmeringsprog. Java kode kompileres til class filer der består af byte code. Endvidere
kan man i java lave applets der kan køres fra en webbrowser.
2. Applikationer programming interface (API)
Javas API består af en base API og en standard extension API. Base består af understøttelse for
grundlæggende grafik, netværk, I/O og utilities. Standard extension indeholder udover dette støtte
for kommercielle produkt, sikkerhed oh media.
3. Virtual machine specifikation
JVM er specifikationer for en abstrakt computer. JVM består af en class loader og en java
interpreter der udfører byte code. Java platformen består af JVM og og Java API og kan køre
ovenpå mange forskellige operativsystemer, som en del af en web browser eller i hardware
En instans af JVM skabes for hver java program eller applet der startes, eller for hver gang en
main() metode startes. Implementationen af selve platformen er speciel for det enkelte system, men
selve java programmet kan køre på en hvilken som helst JVM.
Javas udviklings milieu består af et compile time enviroment og et run time enviroment
Datamatikeruddannelsen efterår 2005
Side 17 af 54
Notater til Teknik 1
Vidar Jon Bauge
Processer
En proces er et kørende program, enten det er et bruger program eller en tjeneste der kører på
systemet. Hvis der kører flere instanser af et program regnes alle instanserne for en selvstændig
proces.
Proces status
En proces ændrer status under kørselen. En proces' status defineres ud fra aktiviteten til processen
•
New – processen oprettes
•
Running – Processen køres
•
Waiting – Processen venter, f.eks. på fuldførelsen af I/O eller en underproces.
•
Ready – Processen er klar til at fortsætte, f.eks efter fuldførelse af I/O, og venter på CPU tid
•
Terminated – Processen er færdig og afsluttes
Diagram over proces status
Datamatikeruddannelsen efterår 2005
Side 18 af 54
Notater til Teknik 1
Vidar Jon Bauge
Proces Control Block (PCB)
Hver proces er repræsenteret i operativsystemet med en proces control block PCB, eller task control
block. PCB'en indeholder alle informationer om en proces, så de
kan bruges når processen en gang bliver læst ind for videre
Pointer
Process state
eksekvering
•
Pointer
Peger på næste PCB i ready køen
•
Process state
Status kan være new, ready, running, waiting etc
•
Process number
Program counter
Registre
Process number
Processen unikke nummer (PID)
•
Program counter
Peger på den næste instruktion der skal udføres
•
CPU Registre
Indholdet af CPU'ens indhold, dvs registre, akkumulatorer, stack
pointer etc
•
Memory limits
List of open files
:
:
CPU scheduling information
Oplysninger som processens prioritet, pegere til scheduler køer og andre parametre for
schedulering
•
Memory management information
Oplysninger om tilladt forbrug af memory, page tables etc
•
Accounting information
Hvor mange ressourcer processen har brugt, CPU tid, real time, time limits, account numbers,
underprocesser etc.
•
I/O status information
En liste over I/O enheder, åbne filer etc der er tilknyttet processen.
Process scheduling
Formålet med multi programmering er at der altid kører en proces for at maksimere udnyttelsen af
CPU'en. Målet med time sharing er at bytte mellem processer så ofte at brugere kan interagere med
programmer mens de kører. For et system med en CPU, vil kun en proces køre ad gangen, de andre
må vente til CPU'en bliver ledig så de kan rescheduleres.
Datamatikeruddannelsen efterår 2005
Side 19 af 54
Notater til Teknik 1
Vidar Jon Bauge
Scheduling queues
Eftersom processer oprettes, bliver de placeret i en job kø. Processer der befinder sig i main memory
og er klare til at blive kørt placeres i ready køen. Køen er som regel implementeret som en linked list.
En ready queue header indeholder en pointer til den første og sidste PCB. PCB'en indeholder en
pointer til næste PCB i ready køen.
Processer der venter på en I/O enhed, bliver placeret i en device queue. Hver enhed i systemet har sin
egen device queue.
En ny proces placeres i ready queue, hvor den venter på at blive dispatched, dvs blive kørt. Når
processen kører kan en af flere ting indtræffe
•
Processen anmoder om en enhed og bliver placeret i device queue
•
Processen opretter en underproces og venter på at den skal blive færdig.
•
Systemet modtager en interrupt, og processen bliver afbrudt og sendes tilbage til ready queue.
I de to første tilfælderne bliver processerne sendt tilbage til ready køen når se events de venter på er
færdige.
Schedulers
En proces flyttes mellem de forskellige scheduling køerne i løbet af sin livs cyklus. Operativsystemet
må vælge fra disse køerne. Denne udvælgelsen foretages af en scheduler. Man taler om tre typer
schedulers
1. Short term scheduler
Tager processer fra ready køen og dispatcher dem. Denne scheduleren må arbejde så hurtig som
mulig, da den skal dispatche mange processer pr sekund – kører mindst en gang pr 100
millisekund. Jo længere tid et context switch tager, jo mere CPU tid bruges på context switch i
stedet for de opgaver CPU'en skal løse
2. Long term scheduler
Vælger processer fra alle åbne processer, loader dem i memory og sætter dem i ready køen. Denne
scheduleren behøver ikke at være så hurtig, da den ikke skal køre så ofte. Udvælgelsen af processer
er imidlertid meget vigtig her. Der skal altid være en blanding af processor tunge og I/O tunge
processer i ready køen. Hvis der bliver ubalance her, får man en ophobning enten i ready køen eller
device køerne.
3. Intermediate scheduler
Nogle operativsystemer har en intermediate scheduler. Dennes opgave er at flytte processer fra
memory til til sekundært memory for at mindske graden af multi programmering (swappe). Når
aktivitet på systemet bliver lavere, flyttes processerne tilbage til memory så de kan køre færdig.
Swapping kan være nødvendig for at balancere processerne i køen, eller frigive memory hvis dette
er nødvendig
Datamatikeruddannelsen efterår 2005
Side 20 af 54
Notater til Teknik 1
Vidar Jon Bauge
Context switch
Det at skifte den kørende proces indebærer at alle data omkring den kørende proces skal gemmes, og
den nye processen loades. Dette gælder alle data, indhold i registre, pointere, status etc. Disse data
gemmes i processens PCB blok. Dette er en context switch.
Tiden en context switch tager er afhængig af hardware understøttelse. SPARC processoren har flere
sæt registre, og context switch sker ved at ændre en pointer. Hvis der er flere processer end register
sæt, kan context switch selvfølgelig ske på den ”konventionelle måde”.
Process creation
En proces kan, ved hjælp af systemkaldet create proces starte flere nye processer. Processen der
skaber en ny proces kaldes parent og den nye processen kaldes child. Hver proces behøver ressourcer
i form af CPU tid, memory, filer, I/O enheder etc. For nogle systemers vegne tildeles child processer
ressourcer fra parents egne ressourcer. På denne måden kan man begrænse antal child processer pr
proces og på den måden forhindre overbelastning af systemet.
Der er også forskel i måden systemer opretter nye processer på. Nogen systemer laver en kopi af
parent processen der så kan overskrives med et andet program, mens andre starter en ny proces med
program navn.
Process termination
En proces afsluttes normalt efter udførelsen af sidste instruktion ved at processen beder om at blive
slettet ved hjælp af systemkaldet exit. Hvis processen skal returnere data til parent proces sker dette
ved systemkaldet wait.
En proces kan stoppe en anden proces med systemkaldet terminate, men dette er som regel begrænset
til at parent processer kan standse en child proces. Mange systemer tillader ikke child processer at
køre videre hvis parent processen bliver afsluttet – cascading termination.
Cooperating processes
Parallelt kørende processer kan være samarbejdende eller uafhængige. En proces er uafhængig hvis
den ikke kan påvirke eller blive påvirket af andre processer. Uafhængige processer kan heller ikke
udveksle informationer. Samarbejdende processer kan både påvirke hinanden og udveksle
informationer. Dette kan være nødvendig af bl.a. følgende årsager:
•
Udveksling af information Eftersom brugere kan ønske at dele en ressource, f.eks. en fil må man
sørge for samtidig adgang
•
Hastighed Hvis nogle opgave skal kunde afvikles hurtigere, må kan dele den ud på flere processer.
Dette kan dog kun gøres hvis systemet har flere CPU'er eller I/O kanaler
•
Modularitet Man kan ønske at dele systemet op i moduler hvor man deler system funktioner ud til
flere processer.
•
Praktisk En enkel bruger er interesseret i at udføre flere opgaver samtidig, f.eks editere, printe og
kompilere samtidig.
En måde processer kan samarbejde på er ved producer-consumer modellen. En proces producerer
data som bruges af en anden, f.eks et print program der producerer tegn der sendes videre til printer
Datamatikeruddannelsen efterår 2005
Side 21 af 54
Notater til Teknik 1
Vidar Jon Bauge
driveren. For at gøre dette muligt, må man have en buffer, som produceren fylder og consumeren
henter data fra. Producer og consumer må være synkroniseret så consumer ikke kan hente data før de
er produceret Unbounded producer-consumer lægger ingen begrænsninger på bufferens størrelse,
noget der er tilfælde ved bounded producer-consumer. I dette tilfælde må produceren vente hvis
bufferen er fuld og consumeren må vente hvis bufferen er tom.
Datamatikeruddannelsen efterår 2005
Side 22 af 54
Notater til Teknik 1
Vidar Jon Bauge
Tråde
En tråd kaldes også en lætvegts-proces og er en enhed der udnytter CPU'en. En tråd har sin egen
thread ID, program counter, et register sæt og en stack. Den deler, sammen med andre tråde, sin kode
sektion, data sektion og ressourcer, som åbne filer og signaler, der tilhører den processen dr har
oprettet dem.
Mange applikationer benytter tråde til forskellige formål. En net læser kan have en tråd til at vise
indholdet på skærmen, en til at hente data fra netværket osv. Applikationer der skal køre mange
instancer af en opgave samtidig kan benytte tråde til dette. F.eks. en web server der servicerer mange
samtidige brugere.
Da Java ikke understøtter asynkron behandling, bruger man tråde i Java for at få samtidig udførsel af
opgaver.
Fordele
1. Responsiveness
Multithreading af interaktive applikationer tillader programmet at køre videre selvom det pålægges
tunge eller tidkrævende operationer. Dette giver en hurtigere responstid.
2. Deling af ressourcer
Tråde deler de ressourcer der er allokeret til den proces der har oprettet dem. Deling af kode
tillader en applikation at have flere tråde i samme adresse rum.
3. Økonomisk forbrug af ressourcer
Allokeringaf memory og ressourcer er kostbart. Eftersom tråde deler ressourcer er de mere
økonmiske og hurtigere i context switch. I Solaris tager en context switch ca 30 gange så lang tid
som at oprette en tråd.
4. Udnyttelse af multi processor arkiktektur
Hver tråd kører på en parallelt på hver sin processor. På en single processor arkitektur byttes det så
hurtig mellem tråde at det ser ud som om de kører parallelt, selvom bare en kører ad gangen.
User og kernel tråde
User threads
User threads understøttes udenom kernen i form af biblioteker.Drmed er du hurtige at oprette, men
hvis kernen er single threaded vil en låst tråd betyde at systemet bliver låst.
Kernel threads
Kernel threads er direkte understøttet af kernen, både oprettelse, schedulering og kontrol. Dette gør
kerne tråde langsommere at oprette og køre. Hvis en tråd bliver blokkeret, kan kernen schedulere en
anden.
Datamatikeruddannelsen efterår 2005
Side 23 af 54
Notater til Teknik 1
Vidar Jon Bauge
Multi threading models
Der findes 3 modeller for multi threading: Many to one model, One to one model og many to many
model.
Datamatikeruddannelsen efterår 2005
Side 24 af 54
Notater til Teknik 1
Vidar Jon Bauge
Tråde i Java
Alle Java programmer består af mindst en tråd, der startes med main() metoden.
Der er to måder at oprette tråde i Java
1. Oprette en klasse der er en underklasse til Thread klassen i Java. For at oprette selve tråden
oprettes et objekt af klassen. Kald af metoden start() sætter tråden i ready køen, hvor den vil blive
kørt.
2. Oprette en klasse der implementeret Runnable interfacet. For at oprette selve tråden oprettes et
objekt af klassen. Derefter oprettes en tråd (Objekt af klassen Thread) der tager vore nye objekt der
implemementerer Runnable som parameter. Kald af metoden start() sætter tråden i ready køen,
hvor den vil blive kørt.
Tråd behandling
Java tilbyder bl.a. følgende API for behandling af tråde:
•
suspend() - Deprecated. Standser den kørende tråd.
•
sleep(int tidsperiode) Standser den kørende tråd i en given tidsperiode
•
resume() - Deprecated Genstarter en suspenderet tråd.
•
stop() - Deprecated Standser kørselen af en tråd. En tråd der er blevet standset med stop(), kan ikke
genstartes med resume() eller start().
En tråds tilstande
1. New
Dette er den tilstand en tråd er i
når den er oprette ved hjælp af
new().
2. Runnable
Når start() kaldes, bliver der
allokeret memory i JVM for den
nye tråden og tråden run() metode
bliver kaldt. JVM skelner ikke
mellem en tråd der skal til at kør
og en tråd der kører. En kørende
tråd er stadigvæk i status
runnable.
3. Blocked
En tråd blokkeres hvis der kaldes
en kommando for dette, dvs.
suspend() eller sleep(). En I/O
operation der afbryder tråden gør også tråden blocked.
4. Dead
En tråd går over til status dead enten ved kald af stop() metoden eller fordi trådens run() metode er
Datamatikeruddannelsen efterår 2005
Side 25 af 54
Notater til Teknik 1
Vidar Jon Bauge
færdig.
Tråde i JVM
I tillæg til Java programmer med forskellige tråde, kører JVM flere asynkrone tråde der står for JVM's
systemopgaver. Dette er tråde til f.eks
•
Garbage collection
•
Timeren, der f.eks. tæller cyckler til sleep() metoden
•
En der tager sig af grafiske hændelser, som klik på en knap i et vindue etc.
Nogle tråde oprettes eksplicit af Java programmet andre af JVM.
JVM og værtens operativsystem
JVM implementeres vanligvis ovenpå operativsystemet. Dette gør det mulig for JVM at skjule
detaljerne omkring implementeringen pådet specifikke operativsystem og skabe et konsistent og
abstrakt miljø der tillader Java programmer at køre på enhver platform der understøtter Java.
Specifikationerne til JVM siger ikke noget om hvordan tråde implementeres i det underliggende
system. Dette bestemmes for hver platform JVM implementeres på. En Java tråd er typisk en user
level tråd, hvor JVM er ansvarlig for kontrol af den.
Wndows NT bruges one-to-one modellen, hvorfor JVM på Windows NT knyttes til en kerne tråd.
På Solaris implementeres JVM som many to many
Datamatikeruddannelsen efterår 2005
Side 26 af 54
Notater til Teknik 1
Vidar Jon Bauge
CPU Scheduling - Basic concepts
Formålet med multiprogramming er at holde en af processerne kørende hele tiden for at sikre
maksimal udnyttelse af CPU'en. I et system med en CPU, kan kun en proces køre om gangen, mens
de andre er i kø. En proces kører indtil den er nødt til at vente på noget, f.eks. at en I/O operation skal
blive færdig. I et simpelt system ville CPU'en vente – dvs at CPU til vil gå til spilde. Med multi
programmering vil en anden proces blive startet i ventetiden. Flere processer gemmes i memory og er
klare til at blive kørt – hver gang en proces må vente, står en anden klar til at blive kørt
CPU-I/O burst cycle
En proces kører normalt i cykler, der veksler mellem CPU tid, CPU burst, og IO, IO burst. En
kørende proces veksler mellem mange korte CPU bursts og færre, men længere IO bursts.
load
vent
store increment
vent
load store
store
på IO
index
på IO
add store
read from file
CPU burst
write to file
I/O burst
CPU burst
....
read from file
I/O burst
CPU burst
....
CPU scheduler
Når CPU'en bliver ledig, henter operativsystemet en proces fra ready køen. Der findes mange
alhoritmer for udvelgelse af processer, men der er CPU schedulerens opgave at vælge en proces.
Preemptive scheduling
CPU scheduling finder sted under følgende omstændigheder:
1. Den aktive proces går til wait status, f.eks. for at vente på I/O eller at en child proces skal blive
færdig.
2. Når en proces går fra running til ready, f.eks. fordi der kommer et interrupt.
3. Når en proces går fra wait til ready, f.eks. fordi at en I/O operation er færdig.
4. Når en proces afsluttes.
For punkt 1 og 4 er der ikke tale om preemptive scheduling, men nonpreemptive eller cooperative
scheduling, en ny proces må scheduleres.
For punkt 2 og 3, er der imidlertid flere muligheder. Under nonpreemptive scheduling vil en kørende
proces køre indtil den bliver afslutte eller går over i wait tilstand. Under preemptive scheduling bliver
an proces afbrudt for at give plads til andre ventende processer. Dette er en vanskeligere opgave, da
den kræver at en proces bliver afbrudt i det rigtige øjeblik. En proces må f.eks. ikke kunde afbrydes
mens den opdaterer vigtige systemdata som f.eks en I/O kø.
Dispatcher
En anden vigtig komponent ved CPU scheduling er dispatcheren. Dette er den modul som overgiver
Datamatikeruddannelsen efterår 2005
Side 27 af 54
Notater til Teknik 1
Vidar Jon Bauge
kontrollen til den proces der valgt til at blive kørt. Dette indebærer følgende operationer:
•
Switching context
•
Skift til user mode
•
Gå til det rigtige sted i programmet og start det på nyt.
Dispatcheren må være så hurtig som mulig eftersom det køres for hver gang der skiftes proces. Tiden
det tager dispatcheren at stoppe en proces og starte den nye kaldes dispatch latency.
Schedulerings alogritmer
First come, First-served
Dette er den enkleste af alle algoritmer. Den processen der beder om CPU'en først, får den allokeret
først. F.eks. hvis man har en CPU tung proces og mange I/O tunge, vil den ene holde processoren for
de andre.
Shortest job first scheduling
Denne algoritmen beregner længden på processernes næste CPU burst, og den processen med den
mindste allokeres CPU tid. Denne algoritmen giver mindst ventetid, da den gennemsnitlige ventetid
går ned. Det største problemet med denne algoritmen er at beregne længden på næste CPU burst.
Priority Scheduling
SJFS-algoritmen er en variant af denne. En prioritet tilknyttes hver proces, den proces med højest
prioritet allokeres CPU tid. En SJFS-algoritme er bare en prioritet algoritme hvor næste CPU burst er
en omvendt prioritet.
Prioritets scheduling kan både være preemptive eller non-preemprive. Når en proces kommer i køen
sammenlignes dennes prioritet med de øvrige. Hvis den nye processen har højere prioritet end den der
kører, kan den kørende blive afbrudt til fordel for den nye.
Et problem med prioritet scheduling er indefinite blocking eller starvation. Dette kan løses ved
aging. Dette er en teknik hvor man gradvis øger processers prioritet, så de ikke bliver liggende i kø i
det uendelige.
Round-Robin scheduling
Denne algoritmen er udviklet specielt til time-share systemer. Den ligner FCFS, men der er lagt til
preemption, så der kan skiftes mellem processerne. RR scheduling må ha en proces kø der er en FIFO
kø. Scheduleren vælger den første på listen. Hvis denne kun varer en ”tidsenhed” bliver den kørt, men
hvis den varer længre, bliver den afbrudt med et interrupt og den næste i køen bliver scheduleret. Den
afbrudte proces placeres så bagerst i køen.
Datamatikeruddannelsen efterår 2005
Side 28 af 54
Notater til Teknik 1
Vidar Jon Bauge
Proces synkronisering
Samarbejdende(Cooperating) processer
En samarbejdende proces er en proces der påvirkes af andre processer. Samarbejdende processer kan
enten dele data direkte i memory (kode og data) eller indirekte gennem filer. Samtidig adgang til data
kan forårsage inkonsistente data.
Producer - consumer
En måde for processer at samarbejde, er ved producer – consumer, hvor en proces leverer data til en
anden. Dette giver følgende algoritmer:
Consumer:
Producer:
while (count == 0) {
//no op
}//end while
while (count == BUFFER_SIZE) {
//no op
}//end while
--count;
++count;
Selvom disse algoritmerne er korrekt hver for sig, vil de ikke fungere korrekt når de kører samtidig i
hver sin proces. Det der kan ske er at både consumer og producer prøvet at opdatere bufferen samtidig
Da disse operationerne ikke bliver udført atomisk, dvs at alle assembler instruktionerne ikke bliver
fuldført, kan man risikere en race condition.
register1 registe count
r2
S0
producer
execute
register1 = count
5
S1
producer
execute
register1 = register1 + 1
6
S2
consumer
execute
register2 = count
5
S3
consumer
execute
register2 = register2 - 1
4
S4
producer
execute
count = register1
6
S5
consumer
execute
count = register2
4
Ifølge ovenstående ender count op med at registrere 4 buffere, hvor det rigtige er 5, Hvis S4 og S5
byttes om vil count vise 6. Denne situationen, hvor resultatet er afhængig af rækkefølgen
operationerne udføres på kaldes en race condition.
Datamatikeruddannelsen efterår 2005
Side 29 af 54
Notater til Teknik 1
Vidar Jon Bauge
Kritisk område (Critical section)
Det første man gør for at kontrollere adgangen til delte ressourcer, er at oprette kritiske områder, og
regulerer adgangen til disse – Hver tråd har et kode segment der er kritisk, hvor man ændrer på fælles
variabler, opdaterer en tabel, skriver til en fil etc. Udførelsen af dette kritiske segment kan kun gøres
af en tråd, og mens denne gør dette er alle de andre udelukket fra at arbejde på de fælles data. Dette
kaldes mutual exclusion.
Løsningen på problemet omkring kritisk område må indeholde 3 krav:
5. Mutual exclusion
Når en proces arbejder i sit kritiske området er alle andre tråde/processer udelukket fra de fælles
data der arbejdes på.
6. Fremgang
Hvis ingen tråde er i sit kritiske område, og der er nogle tråde der venter på at komme ind i sit
kritiske område, kan kun de tråde der ikke er i sit kritiske område bestemme hvilken tråd der må
komme ind i sit kritiske område. Denne beslutningen kan ikke udskydes i det uændelige.
7. Begrænset ventetid
Det er begrænset hvor mange gange andre tråde må komme ind i sit kritiske område efter at en tråd
har bedt om adgang for sit kritiske område. Dette er for at undgå starvation (udsultning).
Semaforer
En anden løsning på problemet med kritiske områder er brug af semaforer. En semafor er en integer
eller boolean variabel der udover initialisering kun tilgås af 2 meroder, P og V. P står for probieren og
V for verhoegen.
Probieren:
Verhoegen:
P(S) {
V(S) {
while S <= 0
;//Do nothing
S--;
}//End P
S++;
}//End V
Modifikation af integer værdien til semaforen i P og V må ændres individuelt, dvs at kun en tråd har
adgang til semaforen ad gangen. I tillæg må test af værdien i P(S) og den mulige ændring i S-- også
foregå uden indblanding fra andre tråde.
Brug
Semaforer implementeres enten som en integer eller en boolean, eller en semafor der tæller eller er
binær. Værdien til en semafor der tæller kan enten ligge inde i en fastsat
En semafor bruges på følgende måde:
Semaphore S; initialiser semaforen
P(S);
Datamatikeruddannelsen efterår 2005
Side 30 af 54
Notater til Teknik 1
Vidar Jon Bauge
Kritisk kode
V(S)
Den største ulempen ved semaforer er at de alle kræver CPU cykler mens de venter. Derfor kaldes
disse semaforer også for spinlocks. Dette kan løses ved at ændre på semaforens P(S) metode, så i
stedet for at køre en uændelig løkke, blokkeres tråden. Dermed flyttes tråden over i en vente kø (wait
queue). Denne tråde bliver startet igen ved at en af de andre trådene, der er færdig i den kritiske
sektion, sender et wakeup signal til en af, eller alle processerne i vente køen.
Så bliver henholdsvis P(S) og V(S) seende sådan ud:
Probieren:
Verhoegen:
P(S) {
V(S) {
while S <= 0 {
add process to queue;
thread.wait();
}
S--;
}//End P
S++;
if(S <= 0) {
remove process from queue
thread.notify(); eller
notifyAll();
}
}//End V
Kaldet af wait() metoden i P(S) sætter tråden i vente status. Så kan den overføres til en vente kø, der
enkelt kan implementeres ved at lave et link field i trådens PCB blok. En måde at implementere køen
på, er ved en FIFO liste hvor første og sidste tråd er lænket til hverandre. En korrekt implementation
af semaforer er imidlertid ikke afhængig af hvordan køen er implementeret.
Det er meget vigtig ved brug af semaforer at den kritiske koden bliver udført atomisk, dvs at alle
CPU instruktionerne i den kritiske koden bliver udført. På et system med en CPU kan man bare
standse interrupts men den kritiske kode køres. På et system med flere CPU'er må man imidlertid tage
specielle forholdsregler.
Deadlocks and starvation
Implementering af en semafor med ventekø kan føre til at to eller flere processer venter på en event
som bare kan skabes af en af de andre ventende processer. Dette kaldes en deadlock.
Hvis 2 processer, P0 og P1, tilgår hver semaforene s og q som vist i tabellen,
kommer processerne til at vente på hinanden. De er begge i wait status, men
begge venter på at den anden skal slippe låsen på hhv. semafor s og q. Et andet
problem der kan opstå ved brug af semaforer er starvation eller indefinite
blocking, hvis en proces bliver stående uendelig i wait køen fordi den ikke kan
få tilgang til den ressource den venter på.
Dining philosopher
Dining philosopher problematikken kan løses ved hjælp af semaforer, men
dette er ikke tilfredsstillende, da den kan føre til deadlock hvis alle filosofferne
Datamatikeruddannelsen efterår 2005
P0
P1
P(s)
P(q)
P(q)
P(s)
....
....
....
....
V(s)
V(q)
V(q)
V(s)
Side 31 af 54
Notater til Teknik 1
Vidar Jon Bauge
bliver sultne samtidig. Dette kan undgås hvis man:
•
Tillader maks 4 filosoffer ved bordet samtidig
•
Kun tillader en filosof at tage en spisepind hvis begge er ledige
•
Asymmetrisk løsning: Filosof med uligt nummer tager først den højre, men med lige nummer tager
først den venstre.
Fejl brug af semaforer
•
V() - kritisk kode – P() Hvis man bytter om på metodekaldene, så man kalder V() før P(), kan
man risikere at flere processer udfører sin kritiske kode samtidig
•
P() - kritisk kode – P() Hvis man kalder P() i stedet for V(), så rækkefølgen bliver P() - kritisk
kode – P(), får man en deadlock, da låsen aldrig bliver frigivet
Monitorer
For at undgå sådanne problemerhar man i stedet for udviklet monitorer i høj niveau sprog. Monitoren
er konstrueret sådan at kun en proces kan gå ind i den om gangen. Dermed behøver programmøren
ikke at kode synkroniseringen – den er implementeret i selve monitoren.
•
En monitor har et sæt definerede operationer der giver gensidig udelukkelse inde i monitoren, dvs
der kan kun være en tråd inde i den ad gangen
•
Monitoren indeholder et sæt status variabler der definerer hvilken tilstand dets objekt befinder sig
i, f.eks. om det er låst
•
En metode der er defineret inde i en monitor kan kun tilgå de variabler der er erklæret lokalt inde i
monitoren. Alle andre variabler skal sendes med som variabler.
Man kan definere sine egne betingelser inde i en monitor. Hver betingelse får sin egen vente kø.
Adgangen styres ved hjælp af metoder – x.wait flytter en proces over i vente køen, x.signal starter en
proces i køen. Den grundlæggende forskel i Javas implementation afmonitorer er at i Java er der kun
en vente kø.
Datamatikeruddannelsen efterår 2005
Side 32 af 54
Notater til Teknik 1
Vidar Jon Bauge
Java synkronisation
En applikation der sikrer konsistens i data selvom om flere processer tilgår dem kaldes thread safe.
Synkronisering i Java lever op til dette.
Bounded Buffer
Bounded Buffer lider af 2 problemer
1. Både producer og consumer bruger busy wait loops hvis bufferen er hhv fuld eller tom
2. Der er fare for race condition eftersom både producer og consumer bruger count
Busy waiting
Busy wait loop bruger CPU tid bare på at vente. Dette kan forhindres ved at kalde metoden
Thread.yield().
Både brug af yield() og busy wait kan forårsage en deadlock pga. JVM's måde at proritere tråde på.
JVM vil alltid sikre at tråden med højest prioritet bliver startet først. Hvis produceren harhøjest
prioritet og bufferen er fuld, vil produceren måtte vente til en anden tråd med samme prioritet kan
hente noget ud fra bufferen. Hvis consumeren ikke har dette, får man en deadlock.
Race condition
For at undgå race condition – og busy waiting – har Java en særlig beskyttelse af kritisk kode. Ved at
erklære koden synchronised, sørger man for at objektlåsen bliver sat når en tråd går ind i den kritiske
koden.
Hvert Java objekt er
associeret med en
Datamatikeruddannelsen efterår 2005
Side 33 af 54
Notater til Teknik 1
Vidar Jon Bauge
objektlås. En tråd skal have denne for at udføre kritiske kode, og ingen andre tråde har adgang til
koden end den tråd der har låsen.
Hvert objekt har så et entry set af objekter der venter på låsen, og dermed adgang til koden. Objekter
har også et wait set, med de tråde der venter på at få låsen.
En deadlock kan stadig opstå hvis f.eks. en producer prøver at skrive til en fuld buffer og man bruger
yield() til at sætte tråden i wait status. Deadlock kan opstå fordi yield() kun starter endre tråde uden at
frigive låsen.
Løsningen på problemet er at bruge Thread.wait() metoden, der både flytter tråden til wait køen og
frigiver låsen. Nu er tråden tilgængelig for consumer tråden, men denne er blocked, og står i wait
køen.
Derfor har Java en metode Thread.notify() der flytter en tilfældig tråd fra wait til entry og forandrer
dens status fra blocked til running. Alternativt har Java en notifyAll() metode der ”vækker” alle
trådene i wait køen.
Datamatikeruddannelsen efterår 2005
Side 34 af 54
Notater til Teknik 1
Vidar Jon Bauge
Deadlocks
Når flere processer skal have adgang til et begrænset antal ressourcerkan opleve at en proces går over
i wait status og ikke kan komme ud af den igen. Det kan den ikke fordi at en anden ptoces holder på
ressourcen, men kan ikke komme videre f.eks. fordi at den venter på at den første proces skal fuldføre
sin opgave. Dette er en deadlock.
Ressourcer:
•
Fysiske: Memory, CPU cykler, I/O enheder, printer
•
Logiske: Filer, objekt lås, monitors
System model
Et system består af et begrænset antal ressourcer. En proces' brug af en ressource sker i følgende
stadier:
•
Request: Hvis en ressource ikke kan tildeles med det samme, må processen vente til den bliver
ledig.
•
Use: Processens brug af ressourcen
•
Release: Processen frigiver ressourcen.
Et sæt af processer er i deadlock når hver proces i sættet venter på en event der kun kan udføres af en
anden proces i sættet.
Deadlock characterization
Betingelser der skal opfyldes
1. Mutual exclusion: Mindst en proces må være i en tilstand hvor den bruger en ressource der ikke
kan deles, så en anden proces må vente hvis den vil bruge ressourcen
2. Hold-and-wait: Der må findes mindst en ressource der holder på mindst en ressource, og venter
på en anden der holdes af en anden proces.
3. Ingen preemption: En ressource kan ikke fratages en proces. Processen holder på ressourcen
indtil den selv frigiver den, f.eks. ved terminering eller processen går over i wait tilstand.
4. Cirkulær venting: Der må eksistere et sæt af ventende processer, hvor P0 venter på en ressource
som holdes af P1. P1 venter på en ressource som holdes af P2 osv
Datamatikeruddannelsen efterår 2005
Side 35 af 54
Notater til Teknik 1
Vidar Jon Bauge
Ressource allokerings graf
En ressourceallokeringsgraf viser hvilke ressourcer, eller
instancer af ressourcer der er tilknyttet hvilke processer. Hvis
grafen ikke viser nogle cykler er der ikke deadlock. Hvis hver
ressource bare har en instans, viser en cyklus at der er opstået
en deadlock
Metoder til at håndtere deadlocks
Deadlock
Der er principielt tre måder at undgå deadlocks på:
1. En protokol der sikrer at systemet aldrig går ind i en
deadlock
2. Man kan tillade at deadlocks opstår og så tage systemet ud
af den
3. Ignorere problemet, og lade som om deadlocks aldrig opstår
Bruges af de fleste operativsystemer inklusive bl.a. Unix og
Java Virtual Machine
Undgåelse af deadlocks
Uden deadlock
Dette er ikke muligt da det kræver at man kan forudse hvilke
ressourcer processerne kommer til at få brug for.
Forebyggelse af deadlocks
Man kan forebygge deadlocks ved at undgå de fire forudsætninger for at en deadlock skal kunde opstå
1. Mutual exclusion: Undgå at bruge mutual exclusion hvor dette ikke er nødvendig, f.eks. ved
åbning af read only ved læsning af filer. Ellers er dette er ikke mulig i praksis, da der alltid vil være
nogle ressourcer der ikke kan deles, som printere eller synkroniseringsmetoder
2. Hold-and-wait: For at undgå dette må man garantere at en proces ikke beder om flere ressourcer
mens den holder på andre ressourcer. En måde at sikre dette på kan være ved at processer beder om
alle ressourcer de trenger før den begynder, eller at en proces der allerede har en ressource ikke
bede om flere. Et problem med dette er imidlertid at det kan være svært at foudse hvad den skal
bede om. I tilæg kan dette medføre at en proces holder på en ressource unødigt længe. I tilæg kan
dette føre til starvation hvis en proces har stort behov for en populær ressource.
3. Ingen preemption: Hvis en proces, der allerede holder en ressource, beder om en til der ikke er
ledig, så bliver alle processens ressourcer preempted. Dvs. at processen fratages alle sine
ressourcer og kan kun startes igen når den får dem tilbage, plus den ønskede ressource. Dette kan
kun gøres med ressourcer der kan afbrydes og startes igen dvs CPU registre og memory space.
Dette er ikke muligt for hardware enheder og objekter, da de kan blive inkonsistente
4. Cirkulær venting: En metode til at undgå cyklisk venting på er at nummerere alle ressourcer og
kræve at en proces beder om en ressource i strigende orden. Har en proces fået tildelt enressource
med nummer 3, kan den ikke få ressource med nummer lavere end 3.
Datamatikeruddannelsen efterår 2005
Side 36 af 54
Notater til Teknik 1
Vidar Jon Bauge
Memory
Med CPU schedulering kan et system køre mange processer på en gang for at øge dets effektivitet.
Dette kræver at der er mange processer i memory samtidig – shared memory
Adresse binding
Før et program kan blive kørt, kommer det over i input queue, hvor det venter på at blive indlæst i
memory. Compileren binder symbolske adresser til relative adresser, feks. Block start + 14 i memory.
Linkeren binder disse til absolutte adresser i memory. Adresse binding kan ske på 3 tidspunkter:
•
Compile time: Absolut kode, programmet skal befinde sig på et bestemt sted i memory når det
køres. For at forandre på dette skal der rekompileres
•
Load time: Relocatable code. Adresserne kan ændres ved at reloade programmet.
•
Execution time: Binding udsættes til run time. Dermed kan processen flyttes under kørsel. Dette
kræver speciel hardware, og er den mest anvendte metode.
Logisk/Fysisk adresse rum
En adresse der er generet af CPU'en omtales
vanligvis som en logisk adresse, hvor i mod en
adresse i selve RAM klodsen, som den ses af
memory unit, betegnes som en fysisk adresse.
Ved adresse binding på compile time og load
time, får man et miljø hvor de logiske og fysiske
adresser er de samme. Ved binding på execution
time er der forskel på logiske og fysiske
adresser.
Logisk adresserum
Dette er den samlede mængde adresser som et
program generer. Disse adresserne er de eneste
CPU'en kan se. Dette kræver speciel harrware
understøttelse (MMU)
Fysisk adresserum
Den samlede mængde fysiske adresser der svarer til det logiske adresserum. Der er mange forskellige
algoritmer der kan udføre denne mapping.
Datamatikeruddannelsen efterår 2005
Side 37 af 54
Notater til Teknik 1
Vidar Jon Bauge
Paging
Paging er en
metode for
memory
allokering der
tillader at det
fysiske
adresserum til
en proces ikke
behøver at
ligge
fortløbende i
det fysiske
adresserum.
Hver adresse
der generes af
CPU'en består
af et page
nummer og en
page offset. Page number bruges som en indeks til en page table. Page table indeholder den første
adressen til hver side i fysisk memory. Denne adressen og page offet sendes til memory unit der finder
den fysiske adressen. Størrelsen på pages er defineret af hardware, og er vanligvis mellem 512 byts og
16Mb og er et tal ophøjet i 2.
Frames (pageframes)
Den fysiske memory er delt op i blokke af fast længde, kaldet frames. Størrelsen er afhængig af hw
Pages
Den logiske memory er delt op i pages af samme størrelse som frames
Pagetable
En tabel der viser hvilke pages der ligger i hvilke frames i den fysiske memory. Når der ikke er virtuel
memory er pagetabellen 1:1.
Når en proces skal afvikles bliver dens pages loadet ind i tilgængelige frames. Alle adresser der bliver
genereret af CPU'en bliver delt op i 2 dele: Page number der er et index nummer i page tabellen og
page offset der viser hvor langt ind i den aktuelle page man skal.
Den største fordelen ved paging er at der ikke opstår ekstern fragmentering. Enhver ledig frame kan
tildeles en proces.
Af ulemper kan så nævnes intern fragmentering, da pages har en fast størrelse, og man ikke alltid kan
udnytte hele pagen. Dette kan til en vis grad reduceres ved at bruge mindre pages, men dette vil
reducere acces tid, da flere pages skal flyttes med mer tid til I/O operationer
Paging nedsætter context-switch time. Da operaivsystemet opretter en kopi af processens page table,
skal denne læses ind ved contex-switch.
Datamatikeruddannelsen efterår 2005
Side 38 af 54
Notater til Teknik 1
Vidar Jon Bauge
Frame tabel
Opeerativsystemet må have informationer om alle tilgængelige frames i memory. Ikke bare dem der
optræder i en proces' page table. Disse informationerne gemmes i frame table. Her gemmes
informationer om hver frame i memory. Tabellen viser om de er frie, og hvis ikke, hvilken proces de
er tilknyttet.
Datamatikeruddannelsen efterår 2005
Side 39 af 54
Notater til Teknik 1
Vidar Jon Bauge
Virtual memory
Virtual memory er en teknik der tillader kørsel af processer der ikke kan være i memory. Virtual
memory får main memory til at fremstå som en stor lagringsplads, der separerer logisk memory fra
fysisk memory. Denne teknikken frigør programmører fra begrænsninger i memory.
Virtual memory er imidlertid vanskelig at implementere, og kan føre til nedsættelse af performance
hvis det bruges forkert.
Instrukser må være i memory for at kunde blive udført. For at reducere forbruget af memory kan man
anvende dynamic loading. Dette er muligt bl.a. af følgende grunde:
•
Programmer kan have rutiner til fejlbehandling der sjeldent bruges
•
Store tabeller med data er ofte allokeret mere memory end der faktisk bruges
•
Nogle funktioner i et program bruges sjældent
Fordele ved dynamic loading:
•
Et program er ikke begrenset til størrelsen af fysisk memory
•
Flere programmer kan køre samtidig, noget der optimerer udnyttelsen af CPU'en
•
Der bruges mindre I/O på at swappe processer ind og ud
Virtual memory er adskillelse af logisk memory fra fysisk memory. Denne opdelinger betyder at en
stor virtual memory stilles til rådighed selvom man bare har begrænset fysisk memory.
Virtual memory implementeres ofte som demand paging, men kan også implementeres som et
segmentation system. Demand segmentation er imidlertid mere komplekst, da segmenter har
variabel størrelse.
Demand paging
Ett system med demand paging ligner til en vis grad et demand system med swapping. Processer
gemmer i secondary memory, vanligvis en disk. Når en proces skal udføres, bliver den swappet ind i
memory. Istedenfor at swappe hele processen, bruges en lazy swapper. En lazy swapper swapper
aldrig en page ind i memory uden at den skal bruges.
En swapper behandler en hel proces i modsætning til en pager, der kun behandler pages.
Begreber
Når en proces skal swappes ind i memory gætter pageren hvilke pages der skal bruges. For at gøre
dette muligt, må man have hardware support der kan skelne mellem hvilke pages der er i memory og
hvilke der ligger på disken.
Dette kan gøres ved valid-invalid bit der sættes i en pages opføring i page table.Hvis denne er sat til
invalid betyder det at pagen enten ikke ligger i processens logiske adresse rum eller at pagen ligger på
disken. Når man prøver at tilgå en page der er invalid, udløses en page-fault trap. Proceduren for at
håndtere dette er som følgende:
•
Kontroller tabellen i PCB for at fastslå om referencen er gyldig eller ugyldig
•
Hvis referencen er ugyldig bliver processen afbrudt. Hvis den er gyldig skal pagen hentes ind.
Datamatikeruddannelsen efterår 2005
Side 40 af 54
Notater til Teknik 1
Vidar Jon Bauge
•
Der findes en ledig frame, f.eks. i free frame list
•
Der sceduleres en disk operation for at hente pagen ind
•
Når disk operationen er fuldført bliver tabellen og page table modificeret så den viser at page er i
memory
•
Processen startes igen ved deninstruktion den blev afbrudt fra.
Pure demand paging
En proces startes uden at nogen pages er læst ind – ingen pages bliver læst ind for de skal bruges.
Dette kan føre til meget langsom kørsel, hvis der skal indlæses mange pages med instruktioner og
data.
Nødvendig hardware support
1. Page table: Tabellen kan indikere om en page er gyldig eller ikke ved hjælp af en valid-invalid bit
eller et sæt af protection bits.
2. Secondary memory: Her placeres de pages der ikke er i primær memory. Sekundær memory er
ofte på en high speed disk, swap device. Den delen af disken der bruges til dette kaldes swap space
eller backing store.
I tillæg til harware support kræves en betydelig mængde software, bl.a. til at starte processen igen
efter en page fault
Hvis en page fault optræder på en fetch instruktion, kan man bare restarte ved at starte fetch igen.
Men hvis en page fault opstår under fetch af en operand, må man først fetch'e og decode
instruktionen, så fetch'e operanden.
Page replacement
Kørsel af flere processer samtidig, kan føre til over allokering af memory hvis hver proces får tildelt
f.eks. 10 pages men bare bruger 5. Dette kan demand paging reducere, så der bliver plads til flere
processer. Hvis en proces så beder om mange pages, og alle ledige frames er brugt, og der ikke er
mere ledig plads i memory kan der gøres flere ting:
•
Processen lukkes med en fejlmeddelse. Dette strider imidlertid imod ideen om demand paging, da
man ønsker at mange processer skal kunde køre på begrænset memory
•
Man kan swappe ud en hel proces med alle dens frames. Dette er en god løsning under nogle
omstændigheder, f.eks. hvis der er processer der har været inaktive over et stykke tid.
•
Man kan benytte en page replacement algoritme til at frigøre plads
Hvis der ikke findes nogle ledige frames, må man finde en der ikke bruges i øjeblikket, frigive den
ved at flytte dens indhold til swap space, og bruge den til den processen der forårsagede en page-fault
trap
Page fault rutinen skrives om så den kan udføre dette:
1. Find den ønskede pages placering på disken.
2. Find en ledig frame:
a) Hvis der er en ledig frame, så bruges denne
Datamatikeruddannelsen efterår 2005
Side 41 af 54
Notater til Teknik 1
Vidar Jon Bauge
b) Hvis ingen frame er ledig, bruges en page-replacement algoritme til at frigøre en victim frame
c) Skriv victim page til disken, og opdater page og frame tabellen.
3. Læs den ønskede frame ind i den frigjorte pagen, og opdater page og frame tabellen.
4. Genstart bruger processen.
Hvis ingen frames er ledige, kræver dette to page overførsler, en ud og en ind. Dette øger den tiden
det tager at betjene en page-fault trap, og øger acces tiden tilsvarende.
Dette kan reduceres ved hjælp af en modify bit eller dirty bit. Hver page eller frame er associeret
med en modify bit i hardware. Denne sættes hvis der skrives til den aktuelle frame eller page. Når en
page skal pages, kan man undersøge om modify bit er sat. Hvis dette er tilfælde, kræver paging at der
skrives til disken. Ved at vælge en page hvor modify bit ikke er sat, kan man spare en I/O operation,
fordi pagen ligger på disken i uændret form. Denne teknikken gælder også read-only pages, f.eks.
binær kode.
Implementering
Der er to problemer der må løses når man skal implementere demand paging. Der skal bruges en
frame-allokation algoritme og en page-rplacement algoritme. Hvis mange processer befinder sig i
memory må man bestemme hvor mange frames der skal allokeres til hver proces. Designet af disse er
meget vigtig, da I/O bruger mange ressourcer. Man ønsker en algoritme der giver færrest mulige faultpage traps.
•
•
•
FIFO page replacement: Dette er den enkleste algoritme. Når en page skal udskiftes, vælger man
alltid den eldste. Dette kan implementeres som en kø, hvor man sætter ind i toppen og tager fra
bunden.
•
Let at programmere
•
God performance hvis den udvalgte page indeholder en initialiseret variabel der ikke bruges
mer
•
Dårlig performance, hvis den ældste page kan være en der bruges meget
•
Giver aldrig fejl, men kan give mange page swithces, da udvælgelsen ikke alltid er optimal
Optimal Page replacement: Skift den page der ikke vil blive brugt på længst mulig tid.
•
Alltid garanteret mindst antal page-fault traps over en given tidsperiode
•
Meget vanskelig at implementere, da den kræver at man kan se frem i tid.
LRU page replacement: Least recently used. Hver page markeres med hvornår den er sidst brugt,
og den ”ældste” bliver byttet ud. Den kigger tilbage i modsætning til optimal page replacement der
kigger frem.
Implementation af tidsmarkering:
•
Counter: Hvert page felt i page tabellen får et tidsfelt, hvor værdien i CPU timeren kopieres.
Dette opdateres hver gang der refereres til en page, bliver dette feltet opdateret. Den page
med den laveste værdi i time reference field, vælges når en page skal pages.
Denne metoden kræver at page table gennemløbes for at finde den page der er sidst brugt.
•
Stack: Man har en stack af page referencer. Hver gang en page bliver brugt, bliver den
placeret i toppen af stacken. Når en page skal udskiftes, henter man så referencen fra toppen,
så har man den der er sidst brugt.
Datamatikeruddannelsen efterår 2005
Side 42 af 54
Notater til Teknik 1
Vidar Jon Bauge
Stacken implementeres som en dobbelt hægtet list, med en peger til den føste og den sidste.
Ved opdaetring skal man så maksimalt ændre på seks pointere
Implementation af LRU kræver betydelig hardware understøttelse. Opdatering af tids feltet i page
table skal opdateres hver gang der refereres til en page. Hvis dette skulle ske ved hjælp af en
interrupt, vil det nedsætte performance betydelig.
•
LRU Approximation Page replacement: Få computer systemer har den hardware der skal til for
at understøtte LRU. Hvis der ikke fndes nogen harwareunderstøttelse, må man bruge FIFO
algoritmen. De fleste systemer understøtter imidlertid en refernce bit der sættes af hardware når
en page bliver brugt.
Der findes 3 LRU modificerede algoritmer der benytter reference bit. De har alle til fælles at man
kun kan se om en page er blevet brugt, og ikke i hvilken rækkefølge:
1. Additional reference bit algoritme:
Hver page tildeles en 8-bit register byte. Denne sættes til 0 ved opstart. Registeret bliver
opdateret på faste tidsintervaller, og hvis en page er blevet brugt, bliver registeret opdateret med
et 1-tal, ellers med et 0. Opdateringen sker hele tiden af til højre. Dette giver en historik over de
sidste 8 intervaller, og man kan udfra dette bestemme hvilken page der skal udskiftes. Hvis det
findes 2 eller flere ens registre, benyttes FIFO.
Antallet bits i registeret er hardware afhængig
2. Second chance algoritme:
Denne algoritmen er
bygget over en FIFO kø,
men hver page har en
reference bit. Hvis denne er
sat til 0, bliver siden
udskiftet. Hvis reference
bit'en er sat til 1 for den
pågældene page en second
chance:
Bit'en sættes tilbage til 0,
ankomsttid bliver sat og
man går videre til næste
page i listen. Dermed kan
pågældende page ikke
komme i betragtning før
alle andre pages har fået en
second chance
Second chance algoritme som cirkulær kø
Alternativt kan Second
Mulige bitmønstre:
chance algoritmen
R,M
implementeres som en ”klokke” med en
circulær pointer. Pointeren finder næste
page der er sat til 0, udskifter denne med 0,0 – Hverken reference eller modify er sat –
egnet for udksiftning
den ønskede frame. Eftersom pointeren
fortsætter, nulstiller den reference bit'ene.
0,1 – Ikke brugt for nylig, men ændret.
Hvis alle reference bit'ene er sat til 1, vil
Udskiftning kræver skrivning til disken.
alle pages få en second chance, og
1,0 – Nylig brugt, men ikke ændret – vil
sandsynligvis snart blive brugt igen.
Datamatikeruddannelsen efterår 2005
Side 43 af 54
1,1 – Både brugt og ændret for nylig.
Second
chance algoritme
”klokke”
Udskiftning
vil kræve som
skrivning
til disken
Notater til Teknik 1
Vidar Jon Bauge
algoritmen reduceres til en ren FIFO algoritme.
3. Enhanced second chance algoritme: Second chance algoritmen kan udvides med en Modify
bit, så man får to bits, først Reference bit så modify bit
Udvælgelse af page sker på samme måde som ved secoond chance clock algoritmen
Det kan være nødvendig at scanne køen flere gange for at finde den page med de laveste
værdier, da pointeren natutligvis kun ”drejer” en vej. Hvis flere pages har samme værdi, vælges
den første.
Den vigtigste forskel fra den almindelige second chance algoritmen er at her kommer det i
betragtning om en page skal skrives til eller ikke før en ombytning. Dermed kan antallet af I/O
operationer tages i betragtning.
Datamatikeruddannelsen efterår 2005
Side 44 af 54
Notater til Teknik 1
Vidar Jon Bauge
Filsystemer
Filer
Gemmes på et non-volatilt media, dvs data går ikke tabt når der slukkes for maskinen. En fil har en
bestemt struktur, efter hvilke type fil det drejer sig om.
•
Tekstfil – Sekvens af karakterer ordnet i linier og i nogle tilfælde også sider
•
Source fil – Indeholder en sekvens af subrutiner
•
Objekt fil – Sekvens af bytes organiseret i blokke der der kan læses af systemets linker.
•
Executable fil – En serie af kodesektioner loaderen kan læse ind i RAM og eksekvere.
Fil attributter
En fil navngives så det er nemt for den menneskelige bruger at referere til den. I tillæg til dette har en
fil en række attributter der indeholder data omkring filen:
•
Navn – Filens navn. Det eneste der gemmes i et format der kan læses af mennesker.
•
Type – Nødvendig for operativsystemer der understøtter flere filtyper.
•
Lokalisering – Pointer til den enheden filen ligger på, og pointer til placeringen på dette device
•
Størrelse – Aktuel størrelse i bytes, words eller blocks og muligvis også største tilladte størrelse.
•
Protection – Informationer omkring hvem der har adgang til filen – læsning, skrivning, kørsel osv.
•
Tid, dato og bruger(ejer)information – Kan gemme oplysninger som: oprettet, sidst ændret, sidst
brugt.
Fil operationer
En fil er en abstrakt data type. For at definere hvad filer er, er det nødvendig at tage i betragtning
hvilke operationer man kan udføre på dem. Operativsystemet har forskellige system calls for at
oprette, skrive, læse, repositionere, slette og forkorte filer.
Her er seks grundlæggende filoperationer, der må betragtes som et minimumskrav for et filsystem:
1. Oprette en fil - To trind: Først må der findes ledig plads til den nye filen, så skal der oprettes en
placering i en mappe. Placeringen i mappen gemmes sammen med filnavn og placering i
filsystemet.
2. Skrive til en fil – For at skrive til en fil laves et system call hvor man specificerer filens navn og de
data der skal skrives til filen. Med disse oplysningerne gennemsøges filsystemet. Systemet sætter
en write pointer der peger på det sted hvor der skal skrives. Denne pointer må selvfølgelig
opdateres efter hver skrivning.
3. Læse fra en fil - For at skrive til en fil laves et system call hvor man specificerer filens navn og
hvor i RAM man ønsker dataene placeret. Med disse oplysningerne gennemsøges filsystemet.
Systemet sætter en read pointer der peger på det sted hvor der skal læses. Denne pointer må
selvfølgelig opdateres efter hver læsning. Mange operativsystemer bruger en current-file-position
pointer både for læsning og skrivning. Dette sparer plads og gør systemet mindre komplekst
4. Repositionere i en fil (file seek) – Mappen søges for den aktuelle fil, og current-file-position
Datamatikeruddannelsen efterår 2005
Side 45 af 54
Notater til Teknik 1
Vidar Jon Bauge
sættes til en given værdi. Repositionering i en fil, behøver ikke at indebære I/O operationer.
5. Slette en fil – Når en fil skal slettes, gennemsøges mapperne efter den ønskede fil, al plads bliver
frigjort og placeringen i mappen bliver slettet.
6. Forkorte en fil – I nogle tilfælde er det ønskelig at fjerne indholdet i en fil, uden at slette den. I
stedet for at skulle slette filen, og oprette den på nyt, kan man bare nulstille filens længde attribut,
og lade de andre stå urørte.
Dette er de seks grundlæggende filoperationer. Andre almindelige filoperationer er append, rename,
copy. Der finde også operationer dersætter filattributter som ejer, rettigheder osv.
De fleste filoperationer kræver et søg igennem mappestrukturen efter filen. For at spare systemet for
dette, venter mange operativsystemer med at åbne filen til den skal bruges aktivt. Operativsystemet
har en tabel med oplysninger om åbnede filer – open-file table. Ved anmodning om en filoperation
bruges en index i denne tabel så søgning undgås. Når processen lukker filen, fjernes referencen til den
i tabellen.
Nogle systemer åbner en fil implicit når den første reference skabes til den, og lukker filen når
processen der bruger den afsluttes. De fleste systemer kræver imidlertid at en fil åbnes og lukkes
implicit. Systemets open call opretterså bare en pointer i open-file tabellen. Denne pointeren bruges
så ved alle I/O kald i stedet for filens navn.
I flerbruger systemer er open/close kaldene mere komplekse, da flere bruger kan have adgang til en
fil. For at administrere dette bruges der typisk tabeller på to niveauer. Hver proces har sin egen tabel
over de filer den åbner. Disse tabellerne henviser så til system open file table. I tillæg har denne tabel
en open count opføring der indeholder det antal processerder har åbnet den aktuelle fil. Når open
count bliver 0, lukkes filen.
Der er flere informationer associeret til en åbnet fil:
•
File pointer – Systemer der ikke har en file offset som en del af read/write system calls må holde
oversigten over læse/skrive positionen med current-file-position pointer. Denne pointeren er unik
for hver proces der arbejder på filen.
•
File open count – Tæller antal processer der har åbnet en fil. Når open count bliver 0, bliver filen
lukket.
•
Disk location of the file – De fleste filoperationer ændrer filens indhold. Information om filens
placering gemmes i RAM for at undgå at læse/skrive til disken ved sådanne operationer.
Nogle operativsystemer understøtter låsning af dele af en fil og åbne den for mange processer. Eller
lægge dele af en fil i RAM og tillade adgang som om det var en fil. Dette kaldes memory mapping.
Når man lukker en fil der er memory mapped, skrives den så til disken. Flere processer kan memory
mappe den samme fil, for at tillade delt adgang. Hver proces har en pointer der peger på den samme
adresse i RAM, hvor filen ligger. Adgangen styres så ved hjælp af mutual exclusion.
Filtyper
Implementation af filtyper gøres for at systemet skal kunde bestemme handlinger for den enkelte fil.
En enkel måde at implementere filtyper på, er ved at filtypen angives som en del af filnavnet, f.eks.
som Dos 8.3 konvention for filnavn.
Under MacOs har filer en attribut med navnet til det program der oprettede filen, og som sættes under
Datamatikeruddannelsen efterår 2005
Side 46 af 54
Notater til Teknik 1
Vidar Jon Bauge
create kommandoen.
Filstruktur
Filtyper kan også angive filstrukturer. Dette kan dreje sig om specielle formater for eksekverbare filer,
eller hvordan operativsystemet behandler specielle filer.
Det kan være et problem hvis et operativsystem understøtter for mange filtyper. F.eks hvis et
operativsystem understøtter en filstruktur der heder ASCII, kan dette forstyrre behandlingen for f.eks
en fil der indeholder programkode.
MacOs forventer at en fil indeholder en data fork og en ressource fork. Ressource fork'en
indeholder data for brugeren, mens data fork'en indeholder de data der gemmes i filen.
Intern filstruktur
Det at finde offset inde i en fil kan være en kompliceret opgave for operativsystemet. Filsystemet er
delt op i blokke med en fast størrelse (Physical record). Det er imidlertid sjældent at de filer (Logical
record) der skal opbevares matcher blokstørrelsen, og der opstår intern fragmentering.
Mange filsystemer løser dette problemet ved at lægge flere logical records i en physical record. I Unix
betragtes filer som strømme, der kan fordeles over blokke som nødvendig.
Størrelsen på logical records, den fysiske blokstørrelse og metode for pakking afgør hvor mange filer
(logical records) der kan placeres i hver blok.
Allokeringsmetoder
Formålet med disse tre metoderne er at give hurtigst mulig adgang til data, samtidig med at man
reducerer søgetiden og spild af harddisk plads i form af intern og ekstern defragmentering.
Fortløbende (Contiguous) allokering
Filer lægges i efterfølgende blokke på disken, Filer defineres ved første blok og længden på filen.
Fordele
•
Meget hurtig – kræver ingen unødige bevægelse af læsehovedet. Kun fra sidste blok på en sylinder
til første blok på den næste
Ulemper
•
Problemer ved at finde ledig plads til en nye filer – first fit og best fit har vist sig at være hurtigere
end worst fit.
•
Når der skal allokeres plads til en ny fil, må der sikres nok plads til hele filen med det samme.
Dette kan enten ske ved at ”overestimere” filstørrelsen, eller ved at man flytter om på diskens
indhold når en ny fil skal oprettes.
•
Ekstern defragmentering – Efterhånden som filer slettes og oprettes, bliver der ”huller”
filsystemet.
•
Under defragmentering, må systemet lukkes, hvorfor man undgår fortløbende allokering på
produktionsmaskiner
Datamatikeruddannelsen efterår 2005
Side 47 af 54
Notater til Teknik 1
Datamatikeruddannelsen efterår 2005
Vidar Jon Bauge
Side 48 af 54
Notater til Teknik 1
Vidar Jon Bauge
Lenket allokering
Filer fordeles på blokke der ikke nødvendigvis ligger fortløbende på harddisken. Der ligger en pointer
til næste blok ved slutningen på hver blok. Filer kan så nemt udvides ved at lægge flere blokke til ved
filens slutning.
Fordele
•
Løser problemerne ved fortløbende allokering.
•
Ingen ekstern fragmentering. Man kan bruge en hvilken som helst ledig blok.
•
Det er ikke nødvendig at angive størrelse når en fil oprettes, da den bare kan vokse så længe der er
ledig plads
•
Det er ikke nødvendig at defragmentere for at skabe ledig plads til nye filer
Ulemper
•
Det at finde en given blok i en fil kræver at man begynder fra starten og går hver blok igennem.
Dette kræver mange læse- og søgeoperationer for læsehovedet.
•
Pointeren i hver blok bruger i sig selv diskplads. Løsningen på dette er i mange tilfælde at
gruppere blokke i clusters
•
Pålidelighed – Hvis en blok i en fil går tabt, er hele filen ødelagt
En variant af lænket allokering er brug af en fil-allokerings-tabel (FAT), der indeholder en tabel over
alle diskens blokke indekseret med bloknumre. Mappe opføringer indeholder en pointer til den første
blok i filen. De næste opføringer i fat-tabellen indeholder så pointere til den næste blok. Denne kæden
fortsætter til til den sidste blok som har en speciel ”sidste blok” opføring i fat-tabellen. Ved at cache
FAT tabellen undgås mange læsninger til disken.
Indekseret allokering
Hver fil har en index blok med henvisninger til de blokke filen ligger på. For at læse en bestemt blok
i en fil, kan man bare slå op i indexblokken og finde blokken. Når en fil oprettes, sættes alle pegerne
til null. Når der skrives til filen, findes en ledig blok, og dens nummer tilføjes filens index blok.
For at undgå for meget spild, kan man organisere index blokkerne på flere måder:
1. Linked scheme. En index blok er normalt en diskblok. For at tillade store filer, kan man lenke
sammen flere indexblokke.
2. Multilevel scheme. En index blok på første nivå peger på et sæt index blokke på andet nivå der i
sin omgang peger på disk blokke
3. Combined scheme. Nogle index blokke på første nivå peger på andre diskblokke, mens andre
peger på indexblokke på andet nivå.
Fordele
•
Ingen ekstern fragmentering
Datamatikeruddannelsen efterår 2005
Side 49 af 54
Notater til Teknik 1
Vidar Jon Bauge
Ulemper
•
Tap af diskplads ved at index blokken selv forbruger plads
Performance
Alle allokeringsmetoder varierer i akksesstid og lagringseffektivitet, og de forskellige metoder er
egnet til forskellig brug.
Et system med med sequential access bør bruge en anden metode end et system med mere random
access.
Datamatikeruddannelsen efterår 2005
Side 50 af 54
Notater til Teknik 1
Vidar Jon Bauge
I/O systemer
De to vigtigste opgaver for en computer er I/O og data behandling. I mange tilfælde er I/O den
vigtigste funktion, f.eks når man åbner en internetside.
Operativsystemets funktion omkring I/O er at kontrollere I/O operationer og I/O enheder.
Der findes mange typer I/O enheder:
•
Lager enheder: Diske, båndstationer, usb-enheder
•
Transmissionsenheder: Netværkskort, modem
•
Human interface enheder: Mus, tastatur, skærm, printer
Eftersom der er så stor mangfoldighed blant enheder, er det nødvendig med en række forskellige
metoder til dette. Disse metoderne udgør samlet kernens I/O subsystem. For at indkapsle de
forskellige enheders egenskaber, laver man device drivers der håndterer den enkelte enhed i forhold
til kernen.
En enhed kommunikerer med systemet via en port, der f.eks, kan være seriel porten. Hvis flere
enheder bruger samme sæt ledninger, taler man om en bus der er et sæt med ledninger og en protokol
der definerer hvordan meldinger sendes over bussen.
En controller er en elektronisk kreds der kan styre en port, bus eller en enhed. Hvis controlleren
kontrollerer en kompleks enhed, f.eks. en SCSI controller, implementeres den ofte på et eget
kredskort, en host adapter.
Nogle enheder kommer med indebygget controller, som f.eks. en harddisk, hvor controlleren sidder
på et kredsløb på selve disken.
I/O operationer
Controlleren har et eller flere registre for data og kontrolsignaler. CPU'en kommunikerer med
controlleren ved at skrive til disse registrene. Selve IO operationen kan så ske på to måder:
•
Specielle I/O kommandoer der beder om en overførsel af en byte til en I/O port adresse. I/O
instruktionen starter trafik over den rigtige bus til enhedens registre.
•
Memory mapped I/O. Controllerens registre er mapped indenfor CPU'ens adresserum. I/O
operationer igangsættes med standard kommandoer der læser og skriver til registrene.
Mange systemer bruger begge metoder. F.eks grafikkortet, hvor controlleren har har I/O porte til
geundlæggende kontrol operationer, men et stort memory område til skærmens indhold eftersom det
ville kræve millioner af mikro instruktioner hvis dette skulle gøres ved hjælp af specielle I/O
kommandoer.
En I/O port består vanligvis af 4 porte: status, control, data-in og data-out. Status registeret består af
bits der kan læses af controlleren og indikerer status, som f.eks om den pågående operation er færdig
eller ikke. Control registeret kan f.eks benyttes til at ændre enhedens mode. Data-in bruges af host der
læser data der er hentet fra enheden, mens data-out bruges af host til at skrive data der skal gemmes
på enheden. Et data register kan bestå af 1 til 4 bytes.
Datamatikeruddannelsen efterår 2005
Side 51 af 54
Notater til Teknik 1
Vidar Jon Bauge
Polling
Den fuldstændige protokol for kommunikation med en enhed kan være ganske kompleks. Men den
grundlæggende handshaking er ganske simpel. Controlleren indikerer sin status v.h.a busy bit der
sættes når den er optaget med en operation, og sættes til nul når den er færdig og klar til næste
instruktion. Værten signalerer sit ønske ved at sætte busy bit i command registeret når der er en
instruktion til kontrolleren.
1. Værten poller busy bit til den er sat til nul.
2. Værten sætter write bit i command registeret, og lægger værdien i data-out registeret.
3. Værten sætter command-ready bit for at vise controlleren at instruktionen er klar.
4. Når controlleren ser dette, sættes busy bit.
5. Controlleren læser command registeret og ser at det er en write kommando. Så læser den read-out
registeret og udfører I/O på sin enhed.
6. Controlleren nul stiller comman-ready bit og error bit i status registeret for at kommunikere at I/O
er fuldført uden fejl. Så nulstilles busy bit for at kommunikere at controlleren er klar til en ny
instruktion.
Denne procedure gentages for hver byte der skal overføres. I trin et er værten busy-waiting eller
polling. Den er i en loop hvor den læser busy bit for at se om den kan få adgang til enheden. På
mange arkiktekturer kan polling klares med 3 CPU cykler: læs register, logisk og branch hvis ikke
nul.
Polling er effektivt, men tager CPU cykler fra andre, kanskje vigtigere opgaver.
Interrupts
CPU'en har et ben der kaldes interrupt request line (irq), der tjekkes efter hver instruktion. Når
CPU'en modtager et signal over irq, gemmes en del af CPU status, f.eks. indholdet i instruction
pointer. CPU'en går så til en interrupt handler rutine der ligger på et bestemt sted i memory.
Interrupt handler finder årsagen til interruptet, udfører de nødvendige handlinger og returnerer
CPU'en til den status den havde inden den modtog interrupt'et. På denne måden kan CPU'en svare på
en asynkron hændelse, som en device controller der er klar til service.
Moderne operativsystemer har imidlertid behov for en mere avanceret interrupt behandling. For det
første er det nødvendig at kunde forhindre interrupts under udførelsen af kritisk kode.
Dessuden er det nødvendig at kunne dispatche til den rigtige interrupt handler for en enhed uden at
polle enhederne for at se hvilken af dem der har sendt et interrupt.
Systemet må kunne skelne mellem interrupts med høj og lav prioritet og svare med en tilsvarende
grad af prioritet.
I moderne computer hardware findes disse egenskaberne i CPU'en og i interrupt controlleren.
De fleste CPU'er har 2 interrupt linier. En nonmaskable, der er reserveret for hændelser som ikke kan
genoprettes f.eks memory fejl. Den anden irq er maskable, og kan slukkes før udførelse af kritisk
kode der ikke må interruptes. Denne linien bruges af device controlleren for at be om service.
Datamatikeruddannelsen efterår 2005
Side 52 af 54
Notater til Teknik 1
Vidar Jon Bauge
Interrupt handleren tager en adresse, der på de fleste systemer er en offset der bruges til opslag i
interrupt vektoren. Denne indeholder memory adresser til specielle rutiner, interrupt handlers.
Formålet med at bruge en vektor er at eliminere behovet for en enkelt interrupt handler der må søge
efter den rigtige rutine til det indkomne interrupt. De fleste systemer har imidlertid flere interrupt
handlers end der er plads i
interrupt vektoren. Da benytter
man interrupt chaining, hvor
interrupt vektoren peger på en
liste over interrupt handlers. Disse
kaldes så en efter en indtil den
rigtige handler bliver fundet.
Interrupt mekanismen
implementerer også interrupt
priority levels. Dette gør det
muligt at udsætte mindre vigtige
interrupts og afbryde udførelsen af
en mindre vigtig interrupt hvis der
skulle komme en med højere
prioritet.
Interrupt mekanismen håndterer
dessuden en række exceptions
som division med nul, page fault,
alle handlinger der får CPU'en til
at udføre en vigtig fejlrutine.
Page fault er et eksempel på en
exception der sender en interrupt.
Interruptet afbryder den kørende
proces og overlader kontrollen til
interrupt handler der gemmer den
kørende proces og sætter den i
Interrupt signal
wait køen. Derefter køres en pager
der schedulerer en I/O operation
for at hente ind en page, schedulerer en anden proces for kørsel og returnerer fra interruptet.
Et andet eksempel findes i implementering af system calls, dvs funktioner der bruges af programmer
for at bruge en service i kernen. Systemet ”bygger” kaldet ud fra det parametre der er givet og udfører
et software interrupt eller en trap.
Direct memory access
Programmed IO (PIO)
Processen at overføre data. Dette indebærer at overvåge controllerens registre, sætte bits og overføre
data byte for byte til read-out registeret.
Datamatikeruddannelsen efterår 2005
Side 53 af 54
Notater til Teknik 1
Vidar Jon Bauge
DMA
For at aflaste CPU'en for denne opgaven implementerer de fleste systemer en speciel processor der
står for denne opgaven, nemlig direct memory access controller (DMA).
For at starte en overførsel skriver værten en DMA command blok til memory. Blokken indeholder en
pointer til datakilden, målet og antal bytes der skal kopieres. CPU'en skriver command blokkens
adresse til DMA kontrolleren, og fortsætter med sine egne opgaver.
1. Device driver får besked om at overføre
data fra disken til adresse x
2. Device driver beder disk kontrolleren
om at overføre c antal bytes fra disken
til buffer på adresse x.
3. disk kontrolleren initierer en DMA
overførsel
4. disk kontrolleren sender hver byte til
DMA kontrolleren.
5. DMA kontrolleren overfører bytes til
adresse x, icrementerer memory
adressen og decrementerer c indtil c=0
6. Når c=0, sender DMA kontrolleren en
interrupt til CPU'en med besked om at
overførselen er fuldført.
Nogle arkitekturer benytter fysiske memory adresser, mens andre udfører direct virtual-memory
access (DVMA) DVMA kan udføre overførsler mellem to enheder der er memory.mapped udenom
CPU'en.
Eftersom DMA arbejder direkte på memory bussen, kan DMA medføre cycle stealing på denne. Brug
af DMA øger alligevel performance fordi det aflaster CPU'en.
Kernebegreber
Selvom den hardware der skal til for at understøtte DMA er meget kompleks, er de vigtigste begreber:
1. Bussen
2. En kontroller
3. En I/O port med dens registre
4. Handshaking mellem værten og en device kontroller
5. Udførelse af handshaking ved hjælp av polling loops eller interrupts
6. Aflastning af CPU'en ved at overlade overførsler til DMA kontrolleren.
Datamatikeruddannelsen efterår 2005
Side 54 af 54