Eksamen DAT 103. Oppgave 2. Kandidatnr.: 145 1) B 2) B 3) A 4) A 5) D 6) C 7) B 8) A 9) A 10) D

Transkript

1 Eksamen DAT 103 Kandidatnr.: 145 Oppgave 1 1) B 2) B 3) A 4) A 5) D 6) C 7) B 8) A 9) A 10) D Oppgave 2 a) Et OS er den administrerende softwaren i en datamaskin. Den bygger på prinsippene om filhåndtering, minnehåndtering, IO-håndtering og prosesshåndtering. Man kan si at OSet har to roller; extendet machine og resource manager. Som en extendet machine (virtuel machine) sørger OSet for å dekke over den stygge koden til hardwaren. All hardware har forskjellig kode, noe som gjør det vanskelig å programmere imot. OSet ligger over hardwaren og kan tilby programmerere tilgang til hardwaren gjennom systemkall. Som en extendet machine har også OSet ansvar for å skjule unøvendig informasjon for brukeren, som interrupts, algoritmer, osv. Som en resource manager sørger OSet for å samle og tildele ressursene i en datamaskin (eks prosessortid, minne, IO, osv) til prosessene. Dette skal gjøres på en rettferdig måte. b) OSx er et veldig tilpasset OS som kun takler noen få IO-enheter. Andre vil rett og slett ikke fungere. Dette gjør at Apple kan velge hvilke enheter som de vil at skal kunne fungere på deres maskiner, noe som gir et dårligere utvalg for brukeren, men muligens en bedre opplevelse i og med at de enhetene som får brukes på Mac er kvalitetssikret og mindre fare for feil i kode. I motsetning til dette kan Windows/Lunix brukes med de aller fleste enheter, de er veldig tilpasningsdyktige. Men til hver enhet følger det med en driver og hvis denne driveren ikke er helt bra laget vil det kunne føre til at OSet krasjer (driveren ligger i OSet, evt at driveren krasjer hvis den ligger i brukermodus).

2 c) Hvor mange bit et OS er på går på hvor mange minneadresser som er mulig å ha. I et 32-bit system vil det være mulig å ha 2^32 adresser, noe som tilsvarer ca 4 GB med RAM, mens i et 64-bit system kan man potensielt ha 2^64 adresser, noe som er veldig mye og som antageligvis vil holde en stund. Det spiller også inn på andre ting, som for eks farger (dybde, skarphet, osv) og andre ting som begrenser seg av minneområdet som et 32-bits system har å tilby. d) Alle tråder innad i en prosess deler prosessens minneområde. Derfor, hvis en tråd i en viss prosess har en fil åpen, vil andre tråder i denne prosesser kunne ha tilgang til samme fil, altså en delt ressurs. Her er det potensiale til en race condition (i og med at vi har med delte ressurser å gjøre), men et program er veldig dårlig dersom det klarer å ødelegge for seg selv på den måten. Hadde filen derimot vært delt mellom prosesser kunne dette vært tilfellet. e) En prosess er et program under eksekvering og bygger på prinsippene om ressursgruppering (minneområde, bruk av ressurser, filer, osv) og eksekvering (den delen der prosessen faktisk blir kjørt på CPUen). Moderne datamaskiner har flere prosesser i sitt system for å øke effektiviteten. Alle prosesser har minst en tråd, som er den delen av prosessen som kjøres på CPUen. For å kunne kalles en prosess og bli kjørt på CPUen må noen ting være på plass, det som definerer prosessen, nemlig PCB (process control block). Denne tabellen inneholder informasjon om prosessen som når den ble opprettet, prioritet, child- og parent-prosesser, hvor mye tid den har fått på CPUen, alarms og signals, samt pekere til minneområdet og stack, osv. Appropos! Alle prosesser får tildelt et eget minneområde som de kan jobbe mot. I et system som bruker paging går dette minneområdet fra 0 til MAKS. Prosesser vet ingenting om hverandres eksistens, alle prosesser tror de er alene i systemet, og det er derfor viktig at minneområdene beskyttes slik at ikke en prosess, ved et uhell, går inn i en annens prosess minneområde. Prosesser har også en stack, en program counter, m.m. som definerer prosessen. Prosesser må opprettes. Dette kan skje ved fire forskjellige situasjoner: 1. System initiering - man starter datamaskinen 2. Interaktivitet - eks at en bruker trykker på et ikon for å starte et program 3. Batch job 4. Systemkall - en annen prosess utfører et systemkall som fører til opprettelse av en ny prosess. På samme måte avsluttes prosesser av forskjellige grunner: 1. Normal exit (frivillig) - prosessen er ferdig med det den skal 2. Error exit (frivillig) - en prosess velger å avslutte som følge av en feilmelding (kanskje for å prøve å fikse problemet) 3. Fatal error (ufrivillig) - en error som gjør at prosessen plutselig avsluttes. 4. kill (ufrivillig) - Når en bruker aktivt går inn og dreper en prosess I mellom disse to situasjonene lever prosessene, og som en del av PCB antyder har de forskjellig status. Disse er Ready, running og blocked. Når en prosess er klar til å kjøres vil den ligge i readykøen og vente på klarsignal fra OSet (gjennom dispatcheren/scheduleren) om å få kjøre på CPUen. Når den får det og er på CPUen har den statusen running. Herfra kan det skje to ting. Dersom planleggeren bestemmer seg for at den har fått nok tid på CPUen vil prosessen flyttes tilbake til ready-køen. Dersom prosessen i mellomtiden har gjort et systemkall, eks lese fra fil, printe noe, osv, vil den bli plassert i blokkert fram til IO sender en interrupt og sier at den er ferdig. Da flyttes prosessen til ready-køen igjen. Når en prosess blir opprettet vil den med en gang kjøres på CPUen, og den kan avsluttes fra hvilken som helst av de forskjellige statusene, avhengig av hvordan avsluttingen foregår. Som sagt; en tråd er den delen av en prosess som kjøres på CPUen. En prosess kan ha flere tråder og disse trådene (innad i prosessen) deler det samme minneområde, åpne filer og andre ressurser som prosessen har. Alle tråder har derimot hver sin stack. Tråder kan kjøres i forskjellige moduser / forskjellig typer tråder. Brukermodus-tråder er tråder som kun arbeider mot prosessens minneområde

3 og data. Fordelen med disse er at de er lette å opprette og fjerne og de trenger ikke context switch på CPUen når de byttes ut. De kan også brukes på systemer som egentlig ikke støtter tråder. Ulempen med disse er at dersom en av de gjør et systemkall mot kjernen vil hele prosessen bli blokkert, noe som er litt i mot hensikten med tråder. I denne situasjonen er det prosessen som vet om trådene og som har en tråd-tabell. For kjernemodus-tråder ligger den nevnte tabellen i kjernen sammen med prosess-tabellen. Disse trådene koster mer å opprette og fjerne og det er derfor vanlig å resirkulere dem når de er ferdige (kan bli problemer rundt dette med tanke på type tråder og bla bla bla). I motsetning til forrige modus blokkeres ikke prosessen dersom det gjøres et systemkall, istedenfor får prosessen fortsette å bruke CPUtiden sin og sender en annen tråd til å kjøres på CPUen. Det tar litt lenger tid å bytte kjernemodus-tråder enn brukermodus-tråder. Hybrid-versjonen av disse er tråder som kjøres i brukermodus, men kjernen er klar over at de eksisterer og har trådtabellen hos seg. f) En kritisk region er ofte en delt ressurs, som for eks delt minne. Problemet med disse oppstår når tilfeldigheter fører til at to eller flere prosesser overskriver hverandres arbeid. Dette kan skje når en prosess kjøres på CPUen, skriver noe til et delt minne og like etterpå blir byttet ut av despatcheren til en annen prosess som overskriver det den forrige gjorde. Når den første prosessen får kjøre igjen vil verdien være forandret, men det vil ikke prosessen merke for den tror den er alene i systemet og tror derfor at verdien er riktig. Utfallet /svaret vil avhenge av rekkefølgen prosessene blir kjørt. Altså har vi fått en race condition. Det er viktig for en programmerer å være oppmerksom når man bruker delte ressurser / kritiske regioner fordi det er programmereren selv som må sørge for å forebygge dem. Dette kan gjøres ved å bruke teknikker som TSL, Mutex, semaphorer, monitor, e.l. Hvis ikke programmereren bruker dette eller ikke bruker det riktig kan det føre til nevnte race condition eller deadlock. g) CPUen er veldig, veldig rask. I hvertfall i forhold til IO-enheter. Når et program kjøres på CPUen og prosessen gjør et systemkall etter IO vil CPUen måtte vente lenge på IO-enheten før den kan kjøre igjen. Ved å ha flere prosesser i minnet kan andre prosesser få kjøre i mellomtiden mens prosessen venter. Dette øker effektiviteten. h) Som allerede nevnt (siden jeg ikke så denne oppgaven før nå...) er race condition en situasjon som oppstår når flere prosesser bruker den samme, delte resurssen/kritiske område og utfallet er avhengig av rekkefølgen prosessene blir kjørt i. Henviser med dette til eksempelet i oppg f. Dette kan skje fordi de som har programmert prosessene ikke har vært oppmerksomme nok til å tenke over at de bruker delte, krittiske ressurser og gjort tiltak mot det (se oppg f), og dispatcheren tilfeldigvis kjører prosessene i en slik rekkefølge at det oppstår en slik situasjon. Denne oppgaven syns jeg var veldig lik oppg f og svaret mitt er kanskje preget av det, men bare for å vise at jeg kan forskjellen på race condition og deadlock. Race condition handler om prosesser som overskriver hverandre, disse er vanskelig å oppdage fordi de ikke gir noen feilmelding og det ikke er noe "feil" med koden. Deadlock er en situasjon der flere prosesser må vente på hverandre for å kunne fortsette, noe som fører til en låst situasjon. Utgangspunktet er veldig likt, kriteriene er veldig like og løsningene er veldig like, derfor blir svaret mitt litt rart... :-) i) I denne situasjonen har vi en deadlock (en prosess venter på en annen prosess som okkuperer en ressurs, mens den andre ressursen ikke kan fortsette fordi den venter på den første ressursen igjen, en ond sirkel...) med starvation (L får ikke kjørt fordi H har høyere prioritet, L vil "sulte ut".) For å løse denne situasjonen bør det brukes en annen teknikk enn busy waiting (noe som er dårlig utnyttelse av CPUen). Et forslag er sleep- og wake up-signaler. Da vil H legges i dvale når den finner ut av det kritiske området er opptatt slik at L får kjørt seg ferdig. Når L er ferdig og forlater det kritiske området

4 vil den vekke opp H med wake up, slik at den kan gå inn i området. Alternativt kunne det vært brukt semaphorer, men da kreves det større endringer i forhold til slik situasjonen er her. j) I et system som bruker paging blir alt minne delt opp i x antall like store pages. I det fysiske minnet ligger det et visst antall (begrenset av type system 32-bit/64-bit, hvor stort RAM), like store page frames med plass til page'ene. Denne struktureringen gjør det mulig at alle prosesser kan ha sitt eget, virtuelle minneområde som begynnner på 0 og går til Maks. Når en prosess kjøres på CPUen og gjør en instruksjon, eks lese noe fra eget minneområde, vil prosessen gi ut en intern adresse for prosessen, en virtuell adresse. For at CPUen skal finne igjen denne virtuelle adressen i det fysiske minnet er det nødvendig å oversette denne. Dette er jobben til MMUen (memory management unit). Den sjekker mot en høyhastighets-cache, TLB (translation lookaside buffer) som inneholder adressene til alle pagene som ligger i minnet, om den ønskede pagen ligger i minnet. Om den gjør det sender MMuen ut den fysiske adressen ut på bus'en og henter opp pagen. Dersom den ikke ligger i minnet vil MMUen sende beskjed til disk kontrolleren om at den skal hente frem ønsket page (prosessen blir i mellomtiden blokkert grunnet IO-forespørsel). Når IO er ferdig og pagen ligger i minnet sendes en interrupt til CPUen som flytter prosessen over i ready-køen, klar for å kjøres videre. k) DMA er en enhet som tar seg av det administrative rundt det å flytte data mellom minne og disk eller IO og minne/disk. Den er til for å kunne avlaste CPUen og la den gjøre andre ting mens DMA tar for seg flytting av data. Alternativet er at CPUen flytter data selv, noe som forårsaker mange interrupts som tar relativt lang tid å behandle for CPUen (interrupt for hver enhet (byte/blokk/) som blir overført). Ved bruk av DMA initierer CPUen DMA til jobben og DMAen utfører. Dermed er det DMAen som mottar alle interruptene, men sender ingen videre til CPUen. DMAen sender bare interrupt når jobben er gjort, bufferet er tømt, eller ved jevne mellomrom. Fordelen er altså at det sparer CPUen for mange interrupts. Ulempen er det at DMAen er veldig mye tregere enn CPUen og at det er tidbesparende at CPUen hadde gjort jobben selv, siden den antageligvis ikke har så mye annet å gjøre allikevel. DMAen er også en fysisk enhet som koster penger å produsere og implementere så det er også en downside. Litt om hvordan den virker. Minnet og IO vet ikke om at DMAen eksisterer og tror at det er CPUen som kommer med kommandoene. Det er heller ikke vesentlig for de som blir brukt av DMAen å vite hva som styrer dem. Det er også forskjell på hvordan de forskjellige DMAene overfører data. Det kan gjøres i såkalt burst mode der DMAen okkuperer bus'ene (også fra CPUen) og gjør jobben sin helt til den er ferdig. Dette er ikke helt bra siden CPU kan bli blokkert fra bus'ene over en lengre periode. Eller så kan DMAen bruke en teknikk kalt cycle stealing der deler av overføringene skjer i tidsrom der CPUen ikke bruker bus'ene fra før. CPUen kan bli litt forsinket men ikke nevneverdig. Overføringen tar også lenger tid. l) Mutex er en form for lås på et kritisk område eller delt ressurs. Det er en enkel form for semaphor, der en bit-variabel (null eller en) uttrykker om området er ledig eller opptatt og kun en prosess kan gå inn i et kritisk område av gangen. Dersom ressursen er ledig vil prosessen kunne sette mutexen til opptatt (dette må skje som en atomic operation - kan ikke bli avbrutt) og gå inn i området (da vil ingen andre kunne bruke ressursen selv om prosessen blir tatt vekk fra CPUen). Når den har gjort seg ferdig oppheves låsen og andre prosesser kan få tilgang. Andre prosesser i kø vil bli vekket (dersom det er flere vil en tilfeldig prosess bli vekket (en av ulempene med mutex i forhold til semaphorer som bruker et køsystem i steden for)). Eksempel (føler avsnittet over var nesten et eksempel i seg selv, men men): En prosess A kommer til en delt ressurs, sjekker mutex. Dersom opptatt setter den seg selv til sleep, dersom ledig setter den mutexen til opptatt og går inn i det kritiske område. Når den går ut av området vil den sjekke om andre prosesser står i kø. Hvis ja, vekke en tilfeldig prosess og la den gå inn, A fortsetter. Hvis nei, sette mutexen til ledig og forlate ressursen.

5 m) Linked list allocation using a table in memory er en måte å strukturere filene på i et filsystem der alle blokkene en fil består av kan fremstilles som en lenka liste der den første delen i denne lista henviser til den første blokken i fila. Når man henter opp en fil vil man i tabellen (som må ligge i minnet) finne den første blokken og hente og lese denne til minnet. Det første som står i en blokk er hvor neste blokk ligger. Dette kan være hvor som helst på disken, det trenger det ikke være struktur på i og med at man bruker en linka liste. Ulempen med denne teknikken er at tabellen alltid må ligge i minnet, det kan også bli relativt lenger søketid etter alle blokkene sammenlikned med andre metoder (vanlig at man derfor skriver i to og to blokker etterhverandre for å minke søketiden). Fordeler kan være at blokkene kan plasseres der det er plass (man trenger ikke omstrukturere minnet) og disken blir derfor mindre fragmentert. n) Det er to metoder. Den ene er linka liste, men siden jeg nettopp har forklart konseptet rundt denne velger jeg å ta for meg bitmap nå. Ved bitmap får alle blokkene et tall, 0 dersom blokken er ledig og 1 dersom den er i bruk. Størrelsen på blokkene har noe å si for hvor stort bitmappet blir og hvor nøyaktig det er. Blokkene på en disk er definert på forhånd, men i andre sammenhenger, der størrelsen pr enhet kan bestemmes har dette en del å si. Dersom blokkene er store tar bitmappet mindre plass fordi det er færre bits som skal settes, men det blir veldig unøyaktig i og med at det kan hende at det bare er en liten del av blokken som er brukt, mens det ser ut som at hele blokken er i bruk. På en annen side kan man ha mindre blokk-størrelser, som gir et større bitmap (som også tar lenger tid å søke igjennom ved behov for tomme blokker), men som gir et mer detaljert bilde av disken og "sløser" ikke bort like mye av den ledige plassen. I et filsystem, når filer opprettes eller det trengs mer plass, blir bitmappet søkt igjennom etter mange nok 0'er som det trengs. For å gjøre dette på en mest mulig effektiv måte og finne det område som passer aller best / utnytter minnet på best mulig måte, finnes det algoritmer for.