Försättsblad till skriftlig tentamen vid Linköpings Universitet Cover page for written exam at Linköping University

Transkript

1 Försättsblad till skriftlig tentamen vid Linköpings Universitet Cover page for written exam at Linköping University Datum för tentamen Date of exam Sal Room Tid Time Kurskod Course code Provkod LADOK code Kursnamn/benämning Course name Institution Department Antal uppgifter som ingår i tentamen Number of assignments Antal sidor på tentamen (inkl. försättsbladet) Number of pages including cover Jour/Kursansvarig Responsible/Examiner Telefon under skrivtid Phone during exam Besöker salen ca kl. Time of exam visit Kuradministratör Course administrator Tillåtna hjälpmedel Allowed aids Övrigt Other information Typ av papper Paper to use Antal anmälda Number of exams TER2 14:00-18:00 TDDI04 TEN1 Operativsystem, realtids- och processprogrammering Concurrent programming, Operating systems and real-time operating systems IDA 7 uppgifter för maximalt 80p 7 assignments for a total of 80 points 6 Klas Arvidsson klaar@ida.liu.se Start + 1h Gunilla Mellheden , gunme@ida.liu.se Ordlista och enkel miniräknare (+,-,*,/) Dictionary and simple pocket calculator (+,-,*,/) Preliminary graded: U < 50% < 3 < 67% < 4 < 84% < 5 Grades may be raised or lowered based on overall impression. Precise, explained and clearly motivated assumptions, statements and reasoning raise the impression and may triple the points. Solve at most one assignment per sheet. Results available within 10 working days. Read all assignments and estimate how many points you can get before you start. Rutigt, linjerat eller blankt No preference 21 1

2 1. (12p) a) Dynamic (continous) allocation. b) Se figur. Först visas ett tomt minne. Sedan har två processer startats. Sedan har den första avslutat. Nu finns två hål i minnet. Sist skall en ny process allokeras. Inget av utrymmena är är stort nog även fast det finns tillräckligt mycket ledigt minne totalt.? c) Bilden ovan är ett exempel på external fragmentation. Ledigt minne kan inte användas för det är utspritt i små bitar ej allokerat över minnesrymden. d) Paging. e) Processen tilldelas en simulerad minnesrymd (logic address space), som delas upp i block (pages) av en viss storlek. Varje block i den simulerade rymden ges sedan ett block (frame), vilket som helst som är ledigt, i den fysiska minnesrymden (physical address space) (som är uppdelad i ett antal lika stora block). En tabell (pagetable), anger var i fysiskt minne varje simulerat block kan återfinnas. Varje gång processen använder en minnesaddress slår CPU automatiskt upp den riktiga adressen genom att använda tabellen. Det sker genom att minnesadressen delas upp i ett sidnummer och ett offset inom just den sidan. Därefter byts simulerade sidnumret ut mot det riktiga sidnumret genom att hämta det från den position i tabellen som simulerade sidnumret anger. Varje position i tabellen har ytterligare flaggor. En för att ange om sidan används och en för att avgöra om informationen på den sidan ändrats sedan den initierades. Försök att slå upp en sida som inte används i tabellen genererar ett pagefault. Det är ett interrupt i CPU, som kommer anropa den hanteringsfunktion operativsystemet angett för det fallet. f) Internal fragmentation. Eftersom blocken har fast storlek kommer varje process att använda lite mer minne än den behöver. Det gör att systemet kommer ha ledigt minne som inte kan användas för det är utspritt över många allokerade block. Andra problem är att pagetable blir väldigt stor om minnesrymden är stor, samt att varje minnesaccess nu kräver ytterligare en access för att slå i tabellen. 2. (8p) a) Snake snappar upp bägges publika nycklar och byter i hemlighet ut mot sin egen. Adam och Eva kommer nu kryptera med Snakes nyckel, och Snake kan avkryptera och därefter omkryptera med Adams eller Evas nyckel. D.v.s: när eva skickar sin publika nyckel tar Snake emot den. Nu skickar Snake sin publika nyckel till Adam (men låtsas att den är Evas). När Snake får publika nyckeln från Adam skickar han sin egen till Eva (men låtsas den är Adams). Detta gör att både Adam och Eva kommer att kryptera med Snakes publika 2

3 nyckel, och han kan enkelt avkryptera med sin privata nyckel. Därefter kan han lika enkelt ändra meddelandet och kryptera med mottagarens publika nyckel. b) Adam och Eva måste verifiera att de verkligen får varandras riktiga nyckel. Det kan göras genom att de träffas, eller genom att någon de redan har säker kommunikation med kan bekräfta motpartens nyckel. c) Assymetrisk kryptering är inte effektivt. De kan använda sina publika nycklar för att utbyta en effektivare nyckel för symmetrisk kryptering. Förutsatt att de med säkerhet känner till att den publika nyckel de fått av motparten verkligen tillhör motparten. 3. (12p) a) Ordbehandlare, musikspelare, terminal, top, grafiskt gränssnitt, klient. b) Minst en för varje process. c) Vi kan vara tämligen säkra på att åtminstone musikspelaren har flera trådar som delar hela processens minne och som den sköter internt med stack och schemaläggning (user-trådar). Det är även troligt att det grafiska användaregränssnittet har flera trådar. Det kan även vara så att musikspelarens trådar är fördelade på trådar i operativsystemet för att kunna utnyttja flera CPU. d) Det gör operativsystemet. e) Det gör processen. Vid tilldelning av en kerneltråd per usertråd eller N kerneltrådar per (N+M) usertrådar är det operativsystemet som står för schemaläggning av kerneltrådarna och därmed implicit även för de kopplade usertrådarna. f) Round-robin med ett time-quanta som ger intrycket att alla processer är aktiva samtidigt. I ett grafiskt användargränssnitt är detta ett krav. Man vill inte behöva vänta på att en process skall bli klar innan nästa blir aktiv, utan köra alla med time-share. g) Ej besvarad. Använd round-robin. Välj time-quanta. Stort värde riskerar att inte ge någon preemtion och därmed leda till FIFO, litet värde ger tidsödande många schemaläggningssteg. Specificera hur du sorterar ready-kön. process arrival length priority P Q R S T

4 4. (18p) a) Olika partition då ett filsystem normalt använder samma allokeringsmetod till alla filer. b) Varje filaccess kräver att rätt block lokaliserasen genom en läsning av indexblocket och en av det sökta blocket. Det ger för de 4 filaccesserna i exemplet 8 diskaccesser. Den nämnda cachen av senast lästa block ger ingen effekt, det är index-blocket som skulle behöva cachas. c) Varje filaccess kräver att rätt block lokaliseras genom att alla block fram till det sökta blocket läses. Det ger för de 5 filaccesserna i exemplet (4)+(1)+(6-1)+(3)+(10-3)=22 diskaccesser (minus representerar effekten av cache där inte riktigt alla tidigare block behöver läsas). d) Det kan noteras att process R läser från slumpmässing filposition (random access) medan process S läser data sekventiellt från start av filen. Indexed allocation är mycket effektivare då random access användas, medan continuous allocation är effektivt vid sekventiell access. Man bör alltså växla filsystem för respektive fil. Det skulle ge 4 diskaccesser för S och 10 för R vilket är dubbelt så bra som tidigare. e) Det kan noteras att access av diskblock växlar mellan accesser i filen link och accesser i filen index. Eftersom blocken ligger en bit ifrån varandra innebär det mycket förflyttning av läsarmen, vilket tar lång tid. Om operativsystemet istället gör ett försök att invänta nästa filacccess från varje process, eller sorterar listan på diskaccesser, så kan blocken läsas i en ordning som minskar förflyttningen av läsarmen. Eftersom förflytting av läsarmen räknas i millisekunder kan det ge miljoner instruktioner i tidsbesparing. Exempel på algoritmer är SSTF, LOOK, Anticipatory. f) Först måste filen lokaliseras på disken via läsning av katalogstrukturen (diskaccesser, långsamt), sedan cachas denna information och annan metadata i en central lista i operativsystemet förrutsatt att den inte redan finns där. Därefter skapas ett filobjekt som hänvisar till den cachade informationen och även innehåller processspecifik information som nuvarande läs och skrivposition. Att göra detta arbete vid varje access vore väldigt ineffektivt. Dessutom behövs den centrala listan på öppna filer i operativsystemet för att kunna synkroniser accesser till samma fil från olika processer. 5. (6p) a) Metoden ifråga är paging, och det innebär att varje logisk minnesaccess resulterar i två fysiska minnesaccesser. Därför används en TLB som cache för att så ofta som möjligt undvika minnesaccessen för uppslagning i pagetable accessen. b) Utan TLB skulle det ta 200ns. Med TLB tar det alltid 10ns för uppslagning i TLB och 100ns för accessen av fysiska minnesadressen. I 5% av fallen tar det sedan ytterligare 100ns för att göra uppslagning i pagetable. I medel alltså ca 115ns, avsevärt bättre än 200ns. 6. (12p) a) Vid ett pagefault startar CPU en interrupt-hanterare (bestämd av OS) för att hantera felet. Med virtuellt minne kommer OS att försöka lokalisera sidan på disk (mycket långsam), och i så fall läsa in den. Detta gör att den minnesaccessen kommer ta många millisekunder, att jämföra med nanosekunder i vanliga fall. Pagefault sker dessutom slumpmässigt beroende på tillfälligheter i schemaläggning och programmens minnesaccessmönster. Effekten blir alltså att exekveringstiden slumpmässigt blir avsevärt längre än normalt, helt oacceptabelt i ett hårt realtidssystem. b) Att en task (process) alltid slutför sin uppgift inom en bestämd tid. 4

5 c) En värsta fallets exekveringstid måste bestämmas för P1, P2 och P3. P4 verkar inte betraktas som en realtidsprocess i frågan och utelämnas. Denna måste inkludera alla effekter av pagefault. Eftersom det i praktiken är svårt att genomföra används inte virtuellt minne. Slutligen måste man visa att garantin i a) alltid uppfylls för P1, P2 och P3, oavsett i vilken ordning olika tasks, inklusive P4, exekverar. d) P1 behöver 10/40=25% CPU-tid. P2 och P3 behöver 20/60+10/60=30/60=50% CPU-tid. Totalt behövs alltså 75% CPU-tid. Används EDF är det en garanti att alla deadlines möts. Används RMA är det bevisat att alla deadlines möts om CPU-belastningen ligger under värdet som ges av formeln 1 -- n n 2 1 där n anger antalet tasks. För 3 taks blir det 77% vilket är mer än 75%, alltså är det möjligt. e) Det kommer medföra ett beroende mellan P1 och P4. Om P4 blockerar det lås som garanterar säker användning av resursen, samtidigt som P4 tvingas vänta på en högre prioriterad realtidstask kommer implicit P1 att vänta på en lägre prioriterad task, vilket gör att deadline då kan missas (priority inversion). 7. (12p) a) Vi behöver först notera att listan på varje index i tabellen är en delad resurs. Sökning och manipulering av den måste synkroniseras. Samt att if exists och senare insert innebär ett beroende. Bryts det kommer dubbletter sättas in. En sekvens: Tråd 1 exekverar set till rad 45 med data med nyckel N Tråd två exekverar hela set med data med nyckel N Tråd 1 fortsätter set och gör en felaktig dubblerande insättning av datat. b) Enklaste synkroniseringslösningen innebär att ett lås används för hela tabellen. Det låses på rad 14 och låses upp på rad 18, låses på rad 38 och låses upp på rad 48. Nu kan endast en tråd i taget exekvera i de kritiska sektionerna. c) Vi observerar att olika index har olika listor och alltså kan användas oberoende av varandra. Vi kan även observera att rad 15 samt rad 39 faktisk bara är en läsoperation för att hämta listan och alltså inte behöver synkroniseras. Vi kan nu deklarera ett lås per index, och så fort en lista hämtats ut från ett index låsa endast det indexets lås, på rad 16 samt på rad 40 och låsa upp indexets lås på rad 18 samt 48. d) Det är onödigt att två trådar som bara läser blockerar för varandra. Genom att applicera ett readers-writers-lås som är gemensamt för alla som läser, men endast för en som skriver kan möjligheten till parallell exekvering ökas. 5

6 01: -- to get the data identified by key from table 02: function get(table : in hash_table_type, 03: key : in key_type) returns stored_type is 05: index : integer; -- 3 variable declarations 07: list : list_type; 09: value : stored_type; 11: begin -- code start here 13: index := hash(key); 15: list := table(index); 17: value := find(list, key); 19: return value; 21: end get; 23: -- to insert the data in the table 24: procedure set(table : in hash_table_type, 25: data : in stored_type) is 27: index : integer; -- 3 variable declarations 29: list : list_type; 31: key : key_type; 33: begin -- code start here 35: key := get_key(data); 37: index := hash(key); 39: list := table(index); 41: if exists(list, key) then -- replace old data 43: remove(list, key); 45: end if; 47: insert(list, data); 49: end get; 6