Høgskolen i Molde Institutt for Informatikk Eksamen in240: Operativsystemer Høsten 2002 SVARFORSLAG:

Transkript

1 1 1

2 Høgskolen i Molde Institutt for Informatikk Eksamen in240: Operativsystemer Høsten 2002 SVARFORSLAG: bokmål Les dette før du begynner: Det er syv (7) oppgaver som skal løses på eget ark. Faglærer vil komme rundt et par ganger og besvare eventuelle spørsmål. Vær presis, gi din tolkning av spørsmålet. Forklar begreper du tar i bruk hvis de er sentrale i besvarelsen, grei ut om de forutsetninger du legger til grunn. Gjør et forsøk på å gi svar i hver oppgave og deloppgave. Bruk din intuisjon og vis resonnementet ditt der du ikke har eksakt viten. Vi ønsker å unngå at kandidaten ved feil glemmer å besvare spørsmål, så vennligst spesifiser hvilke spørsmål du ikke gir svar på. Lykke til! 1. Definer kort program, prosess og tråd. Hvordan realiseres Javatråder i Windows 2000, diskuter kort scheduling av trådene? Hva er fordelene med denne typen mapping i forhold til andre mapping-typer (beskriv kort alternativene)? Hvorfor er det så mange tråder i gang i en JVM (forklar først hva JVM er og gjør)? SVARFORSLAG: En prosess er et program under utførelse. Program ligger ofte i sekundært lager, på en fil. Et program er en serie instruk- Dato: 3. Desember 2002 Tid: kl Hjelpemidler: Kalkulator uten minne (KD) Oppgavesettet består av tre (3) sider inkludert forsiden 2

3 sjoner og data. Et binært program er en serie instruksjoner som en gitt prosessor kan utføre uten oversetting. En prosess består av binærkoden (instruksjonene) og data, sistnevnte klassifiseres ofte i statiske og dynamiske data, pluss stack. En prosess kan lede til en eller flere tråder internt i prosessen. I Windows 2000 implementeres 1:1 mapping mellom kernel- og Javatråder, slik at scheduler kan velge hvilken tråd som er neste i CPU. Både JVM og Windows 2000 bruker preemptiv prioritets-basert scheduling. Javatrådene vil nok bli plassert blant variable prioriteter, d.v.s. mellom 1 og 15; kernel kan booste prioritet av ulike grunner (derav variabilitet). 15 går foran 14, o.s.v. JVM er her Java Virtual Machine, den gir et kjøremiljø for Javaprogram. JVM er laget for mange prosessor-arkitekturer slik at Javaprogram med letthet kan flyttes mellom maskiner med ulik arkitektur. Alternativet til 1:1-mappingen er N:1 (en tråd i kernel for alle trådene i prosessen) noe som gir lav grad av kontroll eller, en kan samle tråder i trådgrupper som får en kerneltråd, hvilket gir noe bedre kontroll så lenge trådene i en trådgruppe har omtrent like behov. Andre fordeler er at en kan øke utnyttelsen av CPU: En prosess som blokkerer vil stoppe i sin helhet; hvis en deler prosessen i flere tråder kan en tråd blokkere mens andre CPU-avhengige fortsetter arbeidet. Til slutt kan en nevne fordeler som at kernel kan terminere en tråd uten at hele prosessen avbrytes; ala fordel med mikrokernel i forhold til monolittisk kernel. Ulempen med finkornet kontroll, derimot, ligger i at kernel har overhead per-tråd, bruker tid og plass for å administrere disse. Javatråder i Windows får egen kerneltråd. Det er som sagt JVM som administrerer kjøringen av Javaprogram, d.v.s. alle trådene programmet resulterer i. Ved oppstarten av programmet blir main()-metoden tildelt en egen tråd samtidig er det allerede igangsatt mange tråder til JVM s interne arbeid, f.eks. garbage collection. 2. Hva er det som gjør at vi må synkronisere parter (tråder, prosesser)? Hva kan gå galt i Java-programmet under, og hvorfor dette kan skje? Hvordan kan vi unngå slike feil i dette eksempelet ved bruk av semaforer eller monitorer? Forklar mekanismen som tilbys i Java for slik synkronisering. Lag gjerne kode som viser hva du mener. public class sjef { class arbeider extends Thread { public arbeider () { 3

4 public void run (int oppdrag) { // arbeider med oppdrag aktive=aktive-1; public sjef () { while (true) { int o = vent_oppdrag(); if (aktive < max_aktive) { aktive=aktive+1; arbeider a = new arbeider(); a.start(o); public static void main (String args[]) { sjef s=new sjef(); private int max_aktive=5; private int aktive=0; SVARFORSLAG: Som sagt i forrige spm., er synkronisering viktig for å unngå at prosesser forkludrer delte data som er under endring av andre samarbeidende/konkurrerende prosesser. Dette kan i eksempet skje hvis kundemottaket skal starte en ny arbeider, mottaket gjør new(), og leser variabel aktive som er 3. Scheduler velger deretter arbeider-b som akkurat er ferdig og skal oppdatere aktive. Denne leser aktive (finner ut at denne er 3) og reduserer aktive til 2. Deretter avsluttes tråden for arbeider-b. Scheduler velger deretter å fortsette med kundemottak som (fremdeles) innbiller seg at verdien i aktive er 3, starter en arbeider og endrer aktive til 4, hvilket blir feil. Sannsynligheten for at dette VIL skje kan diskuteres, det avhenger av arkitektur, implementering av JVM, en kan vurdere dette med at trådenes prioriteter er like og at det derfor vil kunne være vanskelig å fremprovosere synkroniseringsfeil. Det som uansett er viktig i synkronisering er å definere kritiske regioner i aktørenes program og sikre at ingen aktør er innenfor sine kritiske 4

5 regioner samtidig. Et annet viktig moment er å hindre at aktører ikke får tilgang, eller (viktig i realtime) får tilgang innen en viss tidsgrense. Kandidaten som ikke ser at aktive er en delt variabel og derfor en risiko her, vil kanskje foreslå at den kritiske region er inne i arbeiderens oppgave, altså skjult. Dette er ikke uttellende; en må kunne se at det er aktive som er problemet her. Teknikker som kan brukes er semaforer og monitorer. Med bruk av semafor startes metode P() i et tellerobjekt. I Java kunne en lage monitor eller semaforer som synchronized metoder i egne klasser. F.eks. et semaforobjekt med synchronized metode P og V, av typen binær/gate, d.v.s. at bare en kan aksessere den delte ressurs (som er variabel aktive ). Kundemottak og arbeiderne bruker da de synkroniserte metodene P og V før og etter kritisk region. JVM assosierer en lås med semaforobjektet, de som vil bruke metodene legges i en ENTERkø, JVM velger neste bruker derfra og lar denne eie låsen. Når bruker er ferdig med P (eller V) forlater den metoden og JVM kan velge neste. Det er ikke aktuelt å bruke wait() for semaforer; den bruker som har fått tilgang skal alltid gjøre seg ferdig. Den trenger aldri å erklære at den vil vente litt. Wait impliserer at brukeren av JVM legges i en WAITkø og forblir der (alene eller med andre ventende brukere) inntil en annen bruker (som i mellomtiden har fått låsen) sier notify(), hvilket betyr at han er FERDIG med objektet. Dette notify() betyr at JVM flytter en eller alle fra WAITkø til ENTERkø der de igjen kan kjempe/megle om eksklusiv tilgang til ressursen. NB! Kandidater som nevner semaforer som felles tellere og ikke sier noe om at en må forutsette gjensidig utelukkelse i kjøringen av P og V, er optimister. Og: Monitorer er ikke en del av Java, men kan emuleres med bruk av synkroniserte metoder. 3. Forklar kort hva som er hensikten med å utføre korteste jobb først. Nevn kort eventuelle ulemper. Hvordan vil denne formen for scheduling fortone seg i fordelingen av CPU, disk, minne og datalink i et LAN? F.eks. hva er det som er jobben for hver av disse? Hva er det som er kjent som spesielt vanskelig med denne typen scheduling, og hvordan kan en (f.eks. for CPU) gjøre noe for å overkomme vanskeligheten? (Vær litt kreativ hvis du synes dette er et vanskelig spørsmål, for disk og LAN må du nok foreslå noe selv (ikke beskrevet i boken). Vi ser her etter forståelse og abstraksjonsevne.) SVARFORSLAG: Med raskeste jobb først menes at scheduler (for en 5

6 gitt ressurs) velger den jobben som den først vil bli ferdig med. Hensikten kan være å holde kølengeden nede, redusere gjennomsnittlig ventetid. Ulempen kan være at langvarige jobber aldri får slippe til (starvation). Når kandidaten skal relatere dette til de fire ressurs-typene kan en tillate (spesielt for minne og LAN) innovative og spekulerende forslag; for CPU og disk er det i boken beskrevet SJF og SSTF. Oppgaven er vag, kan oppfattes på flere måter. Uansett: For CPU blir denne formen for scheduling identisk med Shortest Job First (SJF). Jobben er et sett av instruksjoner, og det er da den som har (antakelsesvis) færrest instruksjoner i sin CPU burst, som vil bli valgt. SJF kan gi mye kontekstbytting og derfor lavere effektivitet (se senere spm.) For disk er jobben å flytte søkearmen, en velger da den diskjobben som gir kortest forflytningstid (Shortest Seek-Time First (SSTF). En tenker vanligvis ikke på shortest file first (som noen kan komme til å nevne, men det er jo en legitim idé. For minnet s del er jobben det å flytte sider ut av minnet (til fordel for sider som skal inn). Dette tar like lang tid for alle sider, hvis en ser bort fra søketiden (alle sider er jo ellers like store). Men, en bør kanskje ta den som antakelsesvis gir minst fremtidig arbeid, en tar ikke ut en side som en tror vil bli etterspurt i nærmeste fremtid! For LAN vil meldingene har variabel størrelse og en vil velge den som har kortest lengde. Oppgaven innbyr delvis (sier datalink i LAN, kan tolkes vidt) til vurdering av ressurser som kan ligge distribuert hos andre maskiner. Her repliseres egentlig argumentene. Over til vanskeligheten (igjen et vagt formulert spørsmål): En kandidat kan f.eks. relatere dette til realtime scheduling der vanskeligheten ligger i å garantere tidsfrister (og har selvsagt mye rett i det i og en premierer da etter resonnementet). Men, det som har blitt gjentatt i forelesningene om bl.a. SJF, dreier seg om at det er vanskelig (bortsett fra disk og LAN) å finne ut hva som er jobbens lengde hvor lenge varer CPUburst, hvor lang tid tar det før en side skal brukes igjen? Her kan f.eks. eksponensiell glatting brukes for estimering. Siste leste jobblengde/varighet for en prosess er L.sistlest, og tillegges en vekt A; siste estimat er L.estimat og vektlegges 1-A; A er her en vekt mellom 0 og 1. Nytt estimat etter en observasjon: L.estimat=A*L.sistlest+(1- A)L.estimat. Dette er eksemplifisert i boken når det gjelder SJF. Høyere A gir mere vekt til de siste observasjoner. Tilbake til dette med realtime: Tiltak for å takle realtime går på å bruke en form for scheduling ala Earliest Deadline First (EDF) eller Rate-Monotonic Scheduling (RMS) som setter spesielle krav til erklæringer om hvor ofte, hvor lenge etc. for 6

7 hver prosess/tråd som skal ha tilgang til ressursen. Dette med realtime har ikke vært sentralt i kurset. 4. Forklar hvordan circular wait kan unngås. I hvilken forbindelse er dette et viktig problem å unngå? Gir dette prevention eller avoidance? Hvordan er dette temaet relatert til CPU scheduling (vær kreativ)? SVARFORSLAG: Circular Wait kan unngås på flere måter og en kan la kandidaten spinne på ulike løsninger, se hvordan det argumenteres (hvilket er det viktigste). En teknikk beskrevet i boken nummererer ressursene og tillater kun aktørene å be om ressurser med høyere nummer enn ressurser de allerede holder på. En annen teknikk er å (ganske enkelt) nekte en prosess å be om ressurser mens den holder en annen ressurs (max en i gangen). En tredje teknikk ligner på den forrige: Prosessen erklærer det han trenger (alt) og vil kunne starte først når alle ressurser er tilgjengelig (alt-eller-intet). De som foreslår preemption av en prosess snakker om recovery, ikke om det å unngå vranglås. Dette er da et problem innen temaet vranglås, og en trenger bare unngå en av fire kriterium for vranglås: Mutual Exclusion, Hold-and- Wait, No-Preemption og Circular Wait. I dette spørsmålet er det sistnevnte kriterium vi fokuserer på. Det å unngå vranglås er altså det man ønsker ja, har en garanti mot Circular Wait har en faktisk Deadlock Prevention (en garanti). Avoidance, derimot, betyr at en ikke er sikker på å ikke få vranglås, det er usikkerhet i etterspørsel som kan overstige tilbudet av ressurser. I avoidance setter en likevel i gang arbeidet og forsøker å unngå at ressurser tildeles slik at en kommer i usikker tilstand (unsafe). Hvordan kobler kandidaten dette til CPU scheduling? Nok en gang kan en la kandidaten spinne, resonnere seg frem til relasjoner. CPU Scheduling er tildeling av CPU til aktører som er interessert (tråd, prosess). En tråd/prosess kan be om CPU uten å få tilgang til denne, kanskje fordi den har for lav prioritet i et prioritets-basert system som Java. Samtidig kan den holde eksklusivt på et objekt som høyere prioriterte tråder gjerne skulle ha. Hvis en tredje tråd er CPU-intensiv og har prioritet mellom disse to blir det vranglås (se senere spm.). CPU-utnyttelsen er indirekte relatert her, da en kan se på denne for å oppdage vranglås (detection), eventuelt se hvor lenge prosesser har vært ikke-aktive (er disse vranglåste?). Hvis CPU er FCFS fordelt (prosess bruker CPU til han er ferdig med CPUburst) og en prosessen bruker busy-wait på låste objekt, vil denne monopolisere CPU og skape en circular wait, ikke ulik den som ble beskrevet over (prioriteter i Java). 7

8 5. Anta et system med demand paging. Hvor stort fysisk minne kan aksesseres med logisk adresse (P1,P2,P3,D) der P1, P2 og P3 er 8 bit hver, D er 8 bit. Altså et tre-nivå s pagingsystem. Hva blir framesize i eksempelet? Hvordan er dette strukturert i Windows 2000? Forklar generelt hvordan ytelsen og plassutnyttelsen påvirkes av framesize. SVARFORSLAG: P1 kan peke til 2**8=256 rader i en pagekatalog der verdien er P1.val, d.v.s. peker til andre pagekatalog. P2 peker kan peke til 2**8=256 rader i den andre pagakatalog (som P1.val peker til) P2.val er da verdien i denne, en peker til en tredje nivås katalog som da er den egentlige pagetabell som faktisk peker inn i det fysiske minnet. Denne pagetabell starter i P2.val, men det er P3 som er indeksen inne i P2.val P3 kan peke til 2**8=256 rader innenfor denne. Den endelige fysiske frame vil starte i P3.val og det er D som peker innenfor denne fysiske frame. D kan peke til 2**8=256 rader i fysisk frame, i praksis 256 Byte (0.25 KB). Fysisk minne har 256*256*256 frames, d.v.s. 2**(8+8+8)=2**24=16M (litt over 16 million) frames. Med 256 B per frame gir dette 2**32=4 GB. I Windows 2000 brukes to-nivås paging med 10, 10 og 12 bits henholdsvis. Det gir 1K pagedirectory som peker til 1K stykk pagetabeller, hver på 1K (tilsammen 1M rader i alle pagetabeller). Hver frame er 2**12=4KB. Adresserbart minne er 1M * 4 KB = 4 GB. 256 B er i særdeleshet en liten frame, men OK. En kunne hatt veldig store frames (8KB, 16KB, 32KB), som en finner i vanlige system i dag. Stor framesize betyr dog at mye urelevant muligens blir hentet inn, og tar mye overføringstid og plass i minnet; men en reduserer iallefall antall henteoperasjoner. Sistnevnte er viktig hvis bustiden er domenerende, men vanligvis vil diskens søketid dominere, hvilket taler for stor framesize. Liten framesize gir altså mange henteoperasjoner for en gitt mengde, og er en ulempe hvis det er store mengder som skal hentes (gir mange I/O-operasjoner). Men, hvis det er god lokalitet har en ganske god treffsjanse innenfor en liten mengde; en trenger da færre overføringer. Et annet moment er at stor framesize gir færre rader i pagetabell, mindre administrativ minnebruk. 6. Forklar hvordan Windows 2000 kan komme ut for priority inversion. I forbindelse med priority-inversion, skisser hvordan deadlock detection and recovery kan gjøres både generelt sett, og hvordan det faktisk gjøres i Windows SVARFORSLAG: Med priority inversion betyr at en høyere prioritert tråd (HOY) låses fordi den trenger en ressurs MM som er holdt av en lavere prioritert tråd (LAV) LAV holder MM mens HOY holder CPU. 8

9 Selv om scheduler vil frigi CPU når HOY blokkerer på MM er det en viss sjanse for at en middels (MED) prioritert tråd som kun trenger CPU denne tar over CPU slik at LAV likevel ikke kommer i gang med ferdigstillelsen av sin kritiske region. Generelt sett løses dette opp med en priority inheritance protocol, der LAV temporært arver HOY s prioritet for å bli ferdig. Praktisk sett har Windows 2000 et hack der de utfører deadlock detection ved å se hvor lenge trådene har vært IDLE (ikke arbeidet). De som har ventet eksepsjonelt lenge boostes i prioritet (til 15) i en kort periode (deadlock recovery). Dette betyr ikke at de som blir boostet er involvert i en slik låst situasjon. 7. Diskuter kort kontekstbytting (context switching). Relater dette til effektivitet i systemet generelt sett; gi og forklar en formel for effektivitet (utilization). Diskuter effektivitet spesielt i forbindelse med RR scheduling, diskuter hvordan kan vi bedre effektiviteten. Si kort hvordan interaktivitet påvirkes av at du presser effektiviteten opp i RR slik du foreslår og, litt om hvorfor. SVARFORSLAG: Kontekstbytte er arbeidet med å overføre CPU fra en prosess A til en annen prosess B. Arbeidet innebærer at status i A skal lagres (til neste gang A velges av scheduler), B s status skal lastes inn (slik at B starter der den slapp). Arbeidet tar tid og jo mer som må gjøres, jo mindre tid er igjen til produksjon. Effektiviteten er U=PROD/(PROD+ADM) der PROD er tiden prosessene kjører, ADM er tiden operativsystemet bruker til bl.a. kontekstbytter. Jo lengre tid kontekstbyttene tar, jo lavere blir U. I RR scheduling settes det et kvantum Q, dette er tiden en prosess kjører før scheduler velger igjen; neste prosess blir den som har ventet lengst blant de som er i READYkø til CPU. Stor Q (mot uendelig) emulerer FCFS, lav Q (nær 1) emulerer Prosessor-Sharing (PS). Hvis det hver gang skal byttes prosess (køen er større enn 1) blir det hver gang et kontekstbytte og vi får U=Q/(Q+ADM). Effektiviteten bedres enten ved å øke Q eller redusere ADM (kontekstbyttet s tid, bl.a.). Interaktiviteten vil lide under økning av Q. Med interaktivitet menes sluttbrukerens opplevelse av responstid i det tekstlige eller grafiske brukergrensesnittet. Hvis prosesser får kjøre lengre i snitt fordi Q øker tar det i snitt lengre før de interaktive slipper til. Høy Q passer for batchprosessering, der sluttbrukerne ikke venter. 9