DAT kandidatnummer: 142

Transkript

1 DAT kandidatnummer: 142 Oppgave 1: 1) B 2) B 3) A 4) A 5) D 6) C 7) B 8) C 9) A 10) D Oppgave 2: a) Et operativsystem er en samling av systemprogrammer og brukes som et bindeledd mellom brukerprogrammer og den vanskelige hardwaren. Et operativsystem består av 4 kritiske komponenter: prosess, minne, I/O og filsystem. Man kan se på et operativsystem som en sammensettning at Extended machine og Resource manager. Extended machine går ut på å skape et enklere interface å programmere mot. hardwaren i bunnen vil være svært vanskelig å programmere mot, derfor trenger vi operativsystemet som et lag imellom som kan sjule hardwaren. dette gjør det mulig å skrive enklere kode som kan fungere på mange forskjellige enheter. Resource manager går ut på at operativsystemet tar på seg rollen som admin. operativsystemet tar ansvaret for å fordele minne, tid å prosessoren og alle andre ressurser. det er kun operativsystemet som får tildele prosesser minne og flere andre ressurser. dette har med sikkerhet å gjøre. man kan ikke la brukerprogrammer tildele mer minne til seg selv, det vil være katastrofalt. Operativsystemet har alt i alt et hav av viktige oppgaver, blandt annet å starte programmer og tildele minne. Det finnes flere forskjellig operativsystemer, blandt annet monolithic systems, og microkernel systems. Monolithic systems går ut på at hele operativstsmet er samlet i kjernen og kjører da i kernel mode. I et microkernel system prøver man derimot å ha så lite i kjernen som mulig, kun det mest kritiske skal ligge i kjernen og kjøre i kernel mode. Alle andre deler av operativsystemet skal ligge utenfor. Dette har fordelen ved at hvis en lyd driver går på trynet, vil ikke hele maskinen kræsje. I et monolithic system kan hele maskinen kræsje. b)

2 Mac og OSX vil ha en fordel over Windows og Linux i forbindelse med I/O enheter på grunn av at OSX er et mye mer lukket system. Apple er svært selektive på hvilke enheter som fungerer mot sitt operativsystem og sine maskiner. Window og Linux på den andre siden jobber mot at så mange enheter som mulig skal fungere på sine systemer. Dette fører til at tilnærmet ingen enheter som er støttet av OSX skaper problemer ettersom de er spesifikt optimalisert mot systemet (eller systemet er spesifikt optimalisert mot enhetene). Hos Windows og Linux vil man kunne oppleve problemer med visse enheter ettersom de prøver å tilpasse systemene til et utall enheter. De er dømt til å få problemer med noen enheter. Noen vil påstå at Apple er feige i denne sammenhengen. c) Forskjellen mellom et 32 bit system og et 64 bit system er antall mulige adresser som systemet kan adressere. i et 32 bit system har man mulighet til å ha 2^32 mulige adresser (overkant av 4 milliarder) mens i et 64 bit system vil man kunne benytte 2^64 adresser. Dette vil ikke bare føre til støtte for mer fysisk minne (32 bit støtter kun 3-4 GB) men også et mye større virtuelt adresseomåde. I dag blir 64 bit systemer mer og mer vanlig. For kort til siden ble Youtube nødt til å oppdatere til 64 bit system når Gangnam Style nådde over 2,1 milliarder visninger. 32 bit systemet de brukte var ikke beregnet til å telle høyere. d) Alle tråder inne i en prosess deler samme adresseområde, dette gjør det umulig å beskytte de mot hverandre, selv om dette strengt tatt ikke er nødvendig. Hvorfor skulle man programmere programmet slik at trådene jobber mot hverandre? Svaret er dermed ja, en åpen fil vil være en delt ressurs mellom trådene (i samme prosess). Hvis oppgaven derimot sikter til tråder i to forskjellige prosesser vil man kunne ha filen enten som en delt ressurs eller privat. e) Prosess: En prosess er et program under eksikvering. Vi kan bruke Halvard baker kake som eksempel. Selve oppskriften representerer programkoden, Halvard er prosessoren, og handlingen å blande sammen alle ingrediensene og putte de i ovnen er en prosess. Prosesser er en kritisk abstraksjon i et operativsystem, mange vil si at den er den viktigste. Alle prosesser har hvert sitt adresseområde som inneholder programkode, data og stack. I et multiprogrammeringssystem har operativsystemet en prosess tabell, med en entry (PCB - Process Control Block) per prosess som kjører i systemet. PCBen innholder all informasjon om prosess som er kritisk for å kunne bytte mellom forskjellige prosesser på CPUen. PCBen inneholder blandt annet program counter, stack, PSW (program status word), informasjon om hvem som eier prosesser, hvilket minneområde den har, hvilke filer den har, prioritet, modus (bruker og kernel) osv. Tråd: En prosess har på sett og vis to oppgaver, ressursgruppering og eksikvering. Men det er ikke selve prosessen som eksikverer på CPUen, det er det tråden som gjør. En tråd blir ofte kalt en lettvektsprosess ettersom den deler flere egenskaper. På samme måte som at en prosesstabell holder styr på prosessene har man en trådtabell som holder styr på trådene. avhengig av om trådene kjører i brukermodus eller kjernemodus kan det enten være en trådtabell per prosess eller en trådtabell som holder styr på alle trådene i systemet. En entry i trådtabellen kalles TCB (Thread Control Block) og holder på mye av samme informasjonen som PCB, dog ikke like mye, som program counter, stack og prioritet. En prosess kan ha en tråd, eller flere tråder. Alle trådene i en prosess deler samme adreseområde, dette er grunnen til at de kan jobbe sammen. Det gir de også muligheten til å skrive over hverandre og ødelegge for hverandre. Det finnes ingen beskyttelse mellom tråder, for det første fordi det er umulig men også fordi det er unødvendig. Man vil jo programmere trådene til å jobbe sammen, ikke ødelegge for hverandre. Det finnes flere fordeler med å ha flere tråder, og man bruker det ofte når man vil at flere ting skal skje "samtidig" inne i et enkelt

3 program. Trådbytter er mye raskere enn prosessbytter. Ta Word som eksempel. Word vil ofte lagre dokumentet periodevis mens man skriver, hva hadde skjedd hvis man kun hadde hatt en tråd? Da ville man merket deley i skivingen for hver gang dokumentet lagres. ettesom tråden må bytte fra å lytte på input fra brukeren og skrive dette til skjerm, over til å lagre dokumentet. Her er det perfekt med flere tråder, på den måten kan man lage en mye bedre brukeropplevelse. Tråder er svært nyttig og øker utnyttelsen av CPUen. f) En kritisk region er den delen av et program hvor prosessen får tilgang på et delt minneområde. Det delte minneområdet kan være en bit av minnet eller en delt fil blant annet. Det er svært viktig å være bevist på dette når man programmerer ettersom dette kan føre med seg Race conditions. Man kan definere reace conditions ved å si at når utfallet/resultatet er avhengig av hvilken prosess/tråd som avsluttet sist har man race conditions. Si vi har en print spooler mappe med 4 slots. Hvorav de tre først er fulle. Prosess A og prosess B ønsker å skrive ut en fil mer eller mindre samtidig. Først sjekker prosess A verdien til ledig slot, og får tilbake 4. Like etter utføres en context switch (bytter prosess) og prosess B får kjøre, B sjekker også verdien til ledig slot og får tilbake 4, dermed skiver prosess B inn fil 4 i mappen og begynner på en annen oppgave. Når det omsider er prosess A sin tur igjen har den allerede sjekket verdien til ledig slot, og skriver enkelt og greit inn fil 3 i sloten, og skriver dermed over fil 4. Prosess B / brukeren vil vente for evig på en utskrift som aldri kommer. Slike race conditions kan løses på flere måter, gjerne ved bruk av en semafor eller mutex. g) Ettersom prosessorer i dag er mye raskere enn I/O enheter er det svært viktig å ha mange prosesser i minnet samtidig, og bytte mellom de. Hvis man kun skulle hatt en prosess i minnet av gangen ville dette først til svært mye sløsing av CPUen. Hvis CPUen skulle fullført en prosess og deretter lastet inn en ny fra disk ville CPUen måtte vente en mannsalder (følses ihvertfall sånn for CPUen) på den nye prosessen. Vi ønsker flere prosesser i minnet slik at byttet går raskere. Prosesser kan oppføre seg på to forskjellige måter, de kan enten være I/O bound eller compute bound. Når en prosess er I/O bound betyr det at den bruker mye av CPU tiden sin på å vente på I/O, mens en compute bound prosess bruker mye til på å gjøre beregninger på CPUen. Dette gjør at vi ofte vil blande mellom å kjøre mellom I/O bound og compute bound prosesser. Hvis vi skulle ha spart alle I/O bound prosessene til slutt ville alle prosessene stått og ventet på informasjon fra den trege harddisken samtidig. Det er bedre å ta en I/O bound først, få igang harddisken, kjøre en annen prosess i mellomtiden og heller gå tilbake når data fra disk har kommet. h) Dette spørsmålet er nært knyttet til oppgave f). Når utfallet er avhengig av hvilke prosesser som kjører til enhver tid har vi race conditions. Sikter til print spooler eksempelet i oppgave f). En måte å forhindre race conditions på er å forsikre seg om at prosesser ikke kan være i sine kritiske regioner samtidig. Dette kan som nevnt oppnås ved bruk av en semafor eller mutex. Race conditions er en av problemene som faller under IPC (Inter Process Communication). I mange systemer er man avhengig av at prosesser skal kunne jobbe sammen, noe som byr på prolemer. For det første: hvoran skal prosessene kommunisere? Helst et system som ikke involverer interrupt. Nummer to: Hvordan forhindrer man at prosesser kommer i veien for hverandre. Nummer tre: fordan kontrollerer rekkefølgen når dette kreves. i)

4 Oppgaven beskriver en livelock. En livelock gir samme resultat som en deadlock men istedenfor at prosess H er blokkert bruker den all CPU tiden sin på busy waiting. Problemet kan enkelt og greit løses uten å endre scheduling algoritme ved å implementere en mutex eller semafor. Da ville prosess H blitt blokkert slik at prosess L får muligheten til å forlate sin kritiske sektor. I tillegg til priority schedulig finnes det flere algoritmer for interaktive systemer som round robin, lottery scheduling, fair share, og multiple ques. Hvorav den siste er nært beslektet med priority scheduling. Men framfor å ha alle prosessene i en lang kø har man flere køer med forskjellig prioritering på de forskjellige køene. Round robin ville også løst dette problemet. Si at L er i sin kritiske region når den glir byttet ut med H. H blir dermed stående hele sitt tidskvantum og busy waite i forsøk på å entre sin kritiske region. Men til slutt vil tidskvantumet ende og L får kjøre igjen. L gjører dermed ferdig og går ut av sin kritiske region. j) I et paging system har MMUen ansvaret for å mappe de virtuelle pagene til de fysiske page rammene. I et paging system deles det virtuelle adresseområde til et program opp i pages på en gitt størrelse, f.eks 2 KB. På samme måte deles det fysiske minnet opp i page rammer (frames) på lik størrelse. Dette gir oss muligheten til å ha mange prosesser i minnet samtidig, ettersom kun en liten av prosessen trenger å være i minnet av gangen. For å holde orden på alle pagene er bruker man page tables. Avhengig av systemet kan man ha et page table hvor entryene (PTE) er indexert med prosess ID. Men det er mer vanlig av hver prosess har hver sin page table. En entry i page table kalles PTE (Page Table Entry) og inneholder flere bits: caching disables, R bit (referert), M bit (modifisert), beskyttelse (ese/skrive), tilstede (i minne eller ikke) og page frame nummer (hvis pagen er i fysisk minne). Systemet er satt opp slik at en page med adresse 16K - 17K kan ligge hvor som helt i det fysiske minnet. Den trenger ikke ligge på adressen 16K - 17K. Det er MMUen som er ansvarlig for denne oversettelsen mellom pages og page frames. Framfor å måtte sjekke page table i minne ved hver page forespørsel har mange systemer et detikert register som holder på de sist brukte mappingene. Dette registeret sitter ofte på CPUen og heter TLB (Translation Lookaside Buffer). TLB opererer like fort som CPUen og vil ikke foråsake delay. Når CPUen ber om en page sjekkes alltid TLB først, finnes den der (TLB hit) føres den rett over til CPUen. Finnes den ikke der (TLB miss) må MMU sjekke page table i minnet. Hvis pagen i page tabel er mappet til en page frame førses den over fra minnet og forsinkelsen er ikke så alt for stor. Men dersom pagen ikke er mappet til en page frame betyr det at pages ikke finnes i fysisk minne, og må dermed overføres fra disk (page fault). Man har også noe som kalles minor page fault, dette forekommer når pagen ligger i minnet, men det var en annen prosess som brakte den inn i minne. k) DMA (Direct Memory Access) er en av tre I/O metoder. Vi har programmert I/O, interruptdreven I/O og DMA. Hvis CPUen vil overføre ordet KAKE til hardisken vil disse tre metodene gi forskjellige utfall. Ved programmert I/O vil CPUen overføre den først bokstaven og spørre konstant om hardisken er ferdig med forespørselen (busy waiting), etter at den første bokstaven er overført følger den neste ovs. Ved interrupt dreven I/O vil fortsatt en bokstav overføres av gangen, men framfor å bruke busy waiting går CPUen over til å jobbe med en annen prosess i mellomtiden, den får deretter et interrupt når bokstaven er overført, CPUen bytter prosess igjen og fører over en ny bokstav osv. Ved bruk av DMA vil man kunne senke antallet interrups til CPUen som fører til færre context switches. En DMA er en fysisk enhet på hovedkortet som jobber sammen med CPUen. Framfor at CPUen overfører en bokstav av gangen og får et interrupt for hver bokstav overfører CPUen hele ordet til DMAen. DMAen vil deretter jobbe på samme måte som CPUen gjorde tidligere og overfør en og en bokstav av gangen og få et interrupt for hver bokstav. Men DMAen vil kun gi ET interrupt til CPUen når hele ordet er overført. På denne måten vil CPUen få et interrupt framfor 4. Dette reduserer antall context switches, som sparer tid. DMAen har to måter å overføre data i busen på, cycle stealing og burst mode. Ved cycle stealing vil den regelmessig rekvirere busen og overføre små mengder data hver gang. Ved burst mode vil den rekvirere busen skjeldnere, men når den først har den vil den overføre mye informasjon.

5 Dette kan forsinke CPUen hvis den hadde planlagt å bruke busen samtidig. DMA er en god måte å gi færre antall interrupts til CPUen på, når det er sagt er den en fysiske enhet som må betales for. Det er billigere (ressurser/penger) å ikke bruke DMA. l) En mutex er en forenklet semafor som brukes for å forkindre race conditions. En mutex er en variabel som kan ha verien 0 eller 1 (låst, ulåst). Dette er en måte å forsikre seg om at flere prosesser ikke er i sin kritiske seksjon samtidig. Når en prosess ønsker en å gå inn i delt område sjekker den den mutexen, hvis verdien til mutexen er 1 er det ledig og prosessen utfører en mutex_lock. Verdien endres da til 0. Når neste prosess ønsker å gå inn i delt minne sjekker den mutex og ser at verdien er 0. Den prosessen blir da blokkert og må vente på at den først prosessen blir ferdig. Når den første prosessen er ferdig sjekker den om det er noen prosesser som venter, hvis det er det vekker den opp en tilfeldig prosess (mutex støtter ikke køsystem, det gjør en semafor) og endrer ikke verdien tilbake til 1. Hvis det derimot ikke er noen prosesser som venter utfører den mutex_unlock og verdien settes til 1 igjen. Det er verdt å merke seg at en mutex sikrer gjennsidig utelukkelse (mutual exclusion) for å forhindre race conditions, som er en av kriteriene for deadlock. m) Linka liste med tabell i minne er en av fire metoder å allokerer filer på en disk. De fire metodene er kontinuerlig allokering, linka list, linka liste med tabell i minne og i-nodes. Disse metodene holder styr på hvile blokker som tilhører hvilke filer på en disk. Ved linka liste med tabell i minne (FAT - File Allocation Table) kan en fil ha blokker på alle mulige plasser på disken. Måten å holde styr på de er ved å ha en linka liste i en tabell i minne. I denne tabellen er det full oversikt over hvilke blokker som tilhører hvilke filer. Denne metoden er mye bedre og raskere enn linka liste fordi den ikke "ødelegger" blokkstørrelsen ved å ha en peker der. I tillegg trenger man ikke å gjøre flere disk operasjoner for å finne en blokk langt ned i listen. Den store bakdelen med FAT er at hele tabellen er nødt til å være i minnet til enhver tid for at den skal fungere. Dette kan føre til at en stor del av minnet går med til tabellen. Hvis men f.eks har en 1 TB hardisk med en blokkstørrelse på 1 KB trenger tabellen i milliard entryer. Hvis hver entry er på 4 bytes vil tabellen ta mellom 2-3 GB med fysisk minne. FAT ble brukt av Microsoft i MS-DOS, og til og med i dag støtter Windows 8 FAT 16 og FAT 32 i tillegg til NTFS. m) På samme måte som at vi brukte bitmaps og linka lister til å holde styr på ledig plass på minnet kan vi bruke de til å holde styr på ledig plass på hardisken. Ved bruk av en linka liste kan vi ha et bit for ledig/opptatt, et bit (eller flere) for å bestemme hvilken blokk den ledige område eller filen begynner, i tillegg til bits som gir at tall på det antallet blokker hullet eller filen strekker seg over. Listen kan forbedres ved å ha to forskjellige lister, en for ledig og en for uledig. Dette vil gjøre det lettere å finne ledige blokker. Det er flere algoritmer for å søke igjennom en linka liste, blant annet First fit og Next fit. Man er ikke nødvendigvis avhengig av at man har nok sammenhengende antall blokker, med mindre man bruker continious allocation. Ved f.eks FAT vil man kunne ha blokkene på forskjellige plasser på hardisken