Datalogi 1F. K1: Implementering af multiprogrammeringskerne med prioriteret skedulering. af Nikolaj Lundsgaard, Martin Schultz & Jesper Thøfner

Transkript

1 Datalogi 1F K1: Implementering af multiprogrammeringskerne med prioriteret skedulering af Nikolaj Lundsgaard, Martin Schultz & Jesper Thøfner 5 April, 2004

2 INDHOLD INDHOLD Indhold 1 Indledning 4 2 Kernens funktioner og strukturer Opbygning af køstrukturer Lagerhåndtering Opbygning af processer Prioritetsinvertering Afvikling af processer Kerne-ogbrugertilstand Initialisering af processer Skedulering Ældning Processkift Afbrydelser Systemkald Ydre enheder og ur Indlejredeafbrydelser Test Test af put Test af get Testafwake Test af ældning Test af KSelectNewProcess Dokumentation print test net test aging test semaphore test inherit test process test time test Bilag Kildekode ekerne.cc ekerne.h kblib.s kmalloc.cc kmalloc.h queues.h Test programmer puttest.cc gettest.cc waketest.cc agetest.cc

3 INDHOLD INDHOLD nptest.cc

4 1 INDLEDNING 1 Indledning I dette afsnit vil vi kort skitsere projektforløbet. Dette skulle gerne medvirke til at belyse problemstilingerne ved at lave en kerne - samt dokumentere den proces vi har gennemgået for at nå resultatet. Det første vi gjorde, var naturligvis at læse opgaven igennem, og bestemme os for hvordan de basale strukturer skulle opbygges. Dette kan der læses mere om i afsnittet om kernens funktioner og strukturer. Dernæst gik vi - med udgangspunkt i d-kernen - i gang med at få startet en proces op, der skrev en linje ud til skærmen; først i kernetilstand, dernæst i brugertilstand. Det var ikke så nemt at få startet en proces op i brugertilstand, som det beskrives her, men efter en uge eller to, lykkedes det. Sideløbende med det, opbyggedes kald-biblioteket stille og roligt, funktion for funktion. Da vi dette tidspunkt stadig ikke havde en fungerende kerne opbyggedes samtidigt en række testscenarier, der gjorde det muligt, at teste kernens funktioner og strukturer på alpha-udviklingsmaskinerne. Med en opstartet proces i brugertilstand og en række gennemtestede funktioner klar til at hælde ind i kernen, begyndte projektet at tage fart. Det var indenfor ganske kort tid muligt, at få flere af de udleverede tests til at køre ganske hurtigt. Vi fandt, at efterhånden som vi implementerede flere og flere af funktionerne i kald-biblioteket, blev de latente fejl i kernen åbenbaret en efter en. I skrivende stund forefindes nu en fungerende kerne, der er testet af de testprogrammer, der er blevet opbygget i projektets forløb. Da vores egne tests har været en del af projektforløbet har vi også valgt at gøre det til en del af rapporten. Først til sidst i projektforløbet blev afbrydelser fra uret sat til, og straks var der intet der virkede, men efter beskyttelse af regioner omkring processkift kom kernen hurtigt på benene igen. Dette betyder at vi nu har en fuldt fungerende kerne der opfylder alle kravene iopgaven,pånær indlejrede kritiske regioner. 4

5 2 KERNENS FUNKTIONER OG STRUKTURER 2 Kernens funktioner og strukturer 2.1 Opbygning af køstrukturer I vores køstrukturer har vi lavet en del om på den udleverede struktur. Vi har blandt andet fjernet previous-pegeren da vi fandt den overflødig. Med andre ord arbejder vi med enkelthægtede lister i stedet for som i den udleverede køstruktur med dobbelthæhtede lister. På den måde opnås en pladsbesparelse. Derudover har vi ændret den udleverede køstruktur fra at være ikke sorteret til at være sorteret. Det betyder betyder naturligvis at funktionen Put, der lægger elementer i køen er ændret i forhold til den udleverede fil. Ændringen består i at Put er udvidet med et ekstra argument. Dette argument bruges til at angive, hvor i køen elementet skal placeres. Til de processer der er klar til at blive udført har vi en kø(kreadyq) og til sovende processer en anden(kwaitq). Fordelen ved at ændre i køstrukturen er at vi kan genbruge den. Ved at kalde Put med en proces prioritet og KReadyQ kan vi få sorteret vores processer, så processer med højest prioritet ligger forrest i køen. Ved at kalde Put med det tidsrum en proces skal vente i samt KWaitQ får vi placeret processerne i KWaitQ, således at den proces som skal vente i kortest tid før den bliver klar til udførsel ligger forrest i køen. I princippet kunne være det samme om vi brugte den udleverede køstruktur til KWaitQ eller om vi brugte vores egen. I vores køstruktur sortereres der ved indsættelse. Ved brug af den udleverede køstruktur til implementation af KWaitQ, ville det være nødvendigt at sortere, når processer skulle hentes ud af køen. Hvis vi brugte den udleverede køstruktur til vores ventekø, ville vi dog være nødt til at gå på akkord med vores princip om at have en køstruktur der kan bruges overalt i programmet. Et princip der udover at tillade genbrug af kode gør kernen enklere både at implementere samt at vedligeholde. 5

6 2.2 Lagerhåndtering 2 KERNENS FUNKTIONER OG STRUKTURER 2.2 Lagerhåndtering Til funktionerne KMalloc og KFree har vi valgt vores egen implementering fra G1-opgaven frem for den udleverede. Vi har i KMalloc anvendt en bestfitmodel hvor KMalloc finder den hukommelsesklods der passer bedst til den mængde hukommelse, der skal allokeres. Hvis KMalloc finder en sådan klods returnerer den en peger til klodsen og holder op med at søge. For at holde styr på om en hukommelsesklods er allokeret har vi valgt at ændre den mindst betydende bit i vores peger, der normalt altid er 0, til 1 hvis klodsen er optaget. Dette gør vi ved hjælp af en maske som vi kører hen over pegeren. Hver gang KMalloc skal bruge pegeren er vi derfor nødt til at maske denne bit ud for at sikre os at vi bruger den rigtige adresse. Grunden til at vi benytter bitten er for at spare unødvendigt overhead da vi ikke benytter ekstra lager til at gemme denne information. Fx. kunne man ellers have benyttet en hel byte til at gemme informationen i men dette opfattede vi som spild af plads. KMalloc returnerer en peger til det hukommelsesområde, der er blevet reserveret. For at undgå unødvendig fragmentering af hukommelsen slår KFree tomme hukommelsesklodser sammen. KFree gør dog kun dette for klodser der ligger i fremadrettet retning i forhold til den klods som KFree bliver bedt om at frigive. 6

7 2.3 Opbygning af processer 2 KERNENS FUNKTIONER OG STRUKTURER 2.3 Opbygning af processer Kernen skal kunne håndtere flere aktive processer.deterderfornødvendigt, at have en passende struktur til at vedligeholde de nødvendige parametre for at kunne implementere en skeduleringsmekanisme. En process er defineret ved følgende struktur: kstack/ksp: Vi har valgt den strategi at lade hver process have sin egen kernestak, kstack, idet dette giver det simpleste processkift, hvilket der kan læses mere om i afsnittet om processkift. ksp indeholder på ethvert tidspunkt en peger til det øverste element på denne process kernestak. ksp implementeres i kernen som en struct Registers, da en struct netop bliver lagret på stakken i modsætning til en klasse der bliver lagret i hoben. Dette gør det nemt at manipulere med stakken, og således nemt at foretage et processkift. ustack/usp: Ligesom vi har brug for en kernestak til hver proces har vi også brug for en brugerstak, ustack. usp peger til enhver tid til det øverste element på brugerstakken. Disse to er adskilt dels for nemhedens skyld, og dels for sikkerhedens skyld. Det er med denne opdeling ikke muligt for brugerstakken at overskrive kernen eller kernestakken, og det er dermed sikret, at brugerprogrammer ikke kan påvirke kernekald eller lave andre ulykker. Umiddelbart virker det måske overflødigt både at have en peger til hver stak samt at have en peger til toppen af hverstak. Det er imidlertid også unødvendigt i lang tid - lige indtil en proces dør, og dens ressourcer skal frigives. PID: Hver proces er defineret ved et ProcesID. PID bruges ikke til meget andet end systemkaldet getpid(), der returnerer den pågældende proces PID. Dog kunne det i senere versioner bruges til at påvirke andre processer end sin egen. Waketime: I forbindelse med systemkaldet sleep bliver en proces bedt om at gøre sig selv inaktiv i et antal klokcykler. Denne variabel bruges i den forbindelse til at holde styr på hvornår processen skal gøres aktiv igen. Priority: Vi har en værdi til at holde processens prioritet, Priority, der holder den prioritet som processen er blevet oprettet med eller bliver sat til af kernen. AllocQ: Som det sidste har vi en kø der holder styr på det lager som processen har fået allokeret. Grunden til at vi gemmer denne information er at vi bruger den til at frigive processens lagerallokeringer når den ophører med at eksistere. 7

8 2.4 Prioritetsinvertering 2 KERNENS FUNKTIONER OG STRUKTURER 2.4 Prioritetsinvertering Et af kravene til opgaven er at der skal implementeres prioritetsinvertering i forbindelse med binære semaforer. I den semaforstruktur der er udleveret i forbindelse med opgaven findes allerede en kø, der kan holde rede på hvilke processer, der ønsker at få adgang til den kritiske region. Den proces der er aktiv i den kritiske region befinder sig derimod ikke i denne kø, men må ligge i en kø og vente på at blive udført. Semaforstrukturen må derfor indeholde information om prioriteten på den proces, der befinder sig i den kritiske region. Når denne information er tilgængelig kan vi hver gang KWait kaldes afgøre om den proces der kalder KWait har en prioritet der er højere end prioriteten på processen, der befinder sig i den kritiske region. Hvis det er tilfældet skal processen i den kritiske region opprioriteres, så vi undgår at den proces, der har kaldt KWait bliver blokeret af processer med lavere prioritet. Når vi implementerer prioritetsinvertering skal vi sørge for at den udføres transitivt. Vores semaforkøer er sorteret efter processernes prioritet således at processer med den højeste prioritet vil få adgang til den kritiske region næste gang der bliver signaleret. På denne måde sikrer vi os at den proces, der befinder sig i den kritiske region har den højeste prioritet. Vi skal derfor ikke søge køen igennem for at sikre os at vi får udført vores prioritetsinvertering transitivt, men skal blot checke om vi skal ændre prioriteten på den proces, der befinder sig i den kritiske region. Vi har søgt at illustrere problematikken ved indlejrede kritiske regioner med nedenstående tegninger. Kernen i problematikken er, at det ventekald som en proces udfører ikke kommer længere end til den næste kritiske region. Der er således ikke noget der sørger for at dette kald propagerer ind til den inderste kritiske region. Vi kan således risikere at en proces med en høj prioritet bliver blokeret af en proces der ligger i en region som denne proces ikke kan udføre et ventekald på. Processen med den høje prioritet blokeres derfor så længeder ligger processer i klarkøen, der har en prioritet der er højere end prioriteten for den proces, der (på illustrationen) befinder sig i den inderste kritiske region. Den udviklede kerne understøtter ikke indlejrede kritiske regioner. 8

9 2.4 Prioritetsinvertering 2 KERNENS FUNKTIONER OG STRUKTURER kritisk region 1 proces p1 med prioritet 15 kritisk region 2 proces p2 med prioritet 31 ændres til 15 når p1 kalder wait på kritisk region 2 proces p0 med prioritet 0 kalder waitpå kritisk region 1 proces p3 fra klarkøen med prioritet 14 klar til udførsel kritisk region 1 proces p1 med prioritet 15ændres til 0 kritisk region 2 proces p2 med nu med prioritet 15 ændres ikke til 0, da den ikke ved at p0 har kaldt waitpå kritisk region 1 9

10 3 AFVIKLING AF PROCESSER 3 Afvikling af processer 3.1 Kerne- og brugertilstand I kernen opereres med 2 tilstande: brugertilstand og kernetilstand. Der findes en tredje tilstand, nemlig tilstanden under et PAL-kald, men da dette er unikt for alpha, og for øvrigt uden for vores rækkevidde udelades denne. Brugertilstand er den tilstand brugerprogrammer afvikles under. I brugertilstand benyttes processens brugerstak til at holde værdier og funktionskald. Brugerstakpegeren indeholdes i alphaens interne register usp. Usp er ikke et register, der er umiddelbart tilgængeligt. Det kan kun læses når processoren er i kernetilstand og kun med PAL-kaldene PAL rdusp (ReaD UserStackPointer) og PAL wrusp (WRite User- StackPointer). Ved skift til kernetilstand skrivessp til usp ogligeledes genskabes denne ved retur til brugertilstand. Kernetilstand er den tilstand kernens indre funktioner afvikles under. Denne adskillelse mellem brugertilstand og kernetilstand er nødvendig da det er ønskværdigt, at beskytte kernen imod brugerprocessers uforudsigelige adfærd. Det er ambitionen at selv hvis en brugerproces skulle havne i uendelig løkke eller terminere uventet, så vil kernen kunne køre ubemærket videre. Ligeledes er der også en ide i at beskytte kernens lagerområde, således at det ikke er muligt for brugerprocesser at udføre kerneinstruktioner samt læse og/eller skrive til kernens interne variable. Da begge tilstande - naturligvis - skal afvikles på samme cpu, og da der kun er et begrænset antal registre til rådighed er det nødvendigt at kunne skifte imellem de to tilstande. Der skiftes fra brugertilstand til kernetilstand automatisk gennem interrupts og systemkald. Interrupts indtræffer når processorens opmærksomhed er ønsket af en ydre enhed. Systemkald indtræffer når processorens opmærksomhed er ønsket af en brugerproces. Til at holde styr på hvilken tilstand instruktionerne afvikles under haves et internt register i cpu en, kaldet statusregisteret - ps. Dette register indeholder to informationer. Bit 3 angiver tilstanden; kernetilstand (værdi = 0) og brugertilstand (værdi = 1). Derudover angiver bit 0-2 (begge inkl.) det sidste afbrydelsesniveau. Altså hvis processorens afbrydelsesniveau er 3 (indikerer at en ydre enhed har afbrudt), og der afbrydes med niveau 5 (uret afbryder), så vil statusniveauet, bit 0-2, indeholde 011, altså 3, og ps[0-2] vil indeholde 101, atså 5. Når en afbrydelse indtræffer sættes en kædereaktion i gang. 1. Brugerprogrammet standser sin udførsel. 2. Processoren dumper en PAL-stakramme på stakken indeholdende flg. 6 registre ps, gp, pc og a0-a2. 3. Med pc (Program Counter) sikkert gemt på stakken hoppes der nu til det rette entrypoint angivet ved kernens initialisering. 4. Dette entry-point er for interrupts angivet til at være ent int. På dette sted i programmet pushes de 30 registre på stakken og derefter kaldes KInterrupthandler - en kernefunktion, der sørger for at behandle den indkomne interrupt. 5. Efter færdigbehandling genskabes de 30 registre + PAL-stakrammen fra stakken 10

11 3.2 Initialisering af processer 3 AFVIKLING AF PROCESSER 6. og brugerprocessen fortsætter, der hvor den kom fra. 3.2 Initialisering af processer Som nævnt i afsnittet om processer indeholder en proces en række variable der skal oprettes korrekt for at sikre korrekt udførsel af de enkelte processer. Der skal allokeres en kernestak og en brugerstak pr. proces. Kernestakken sættes konsekvent til 0x1000. Brugerstakkens størrelse varierer. Den initielle brugerproces stak sættes til default-værdien 0x1000. Alle efterfølgende processer oprettes med en passende størrelse stak, bestemt af brugeren ved oprettelsen af brugerprocessen. De øvrige værdier sættes til noget fornuftigt. AllocQ initialiseres, PID tildeles et unikt id, og waketime sættes til 0 for at indikere, at denne proces endnu ikke har kørt. Det er et specialtilfælde første gang en proces køres. Mere om dette i afsnittet om processkift. Det sidste der skal gøres inden processen sættes ind i skeduleringen varetaget gennem klarkø, KReadyQ, er at manipulere kernestakken, så den ligner stakrammen i forbindelse med retur fra et interrupt, som gennemgået i afsnittet om kerne- og brugertilstand. Processens kernestak initialiseres således til flg.: 30 Regs <- sp a0-a2 gp pc ps PCB PCB, Process Control Block, indeholder processens struktur, som forklaret i afsnittet om processer. ps, statusregisteret, sættes til 8, binært 1000, for at indikere bit[3] = 1, brugertilstand, og bit[0-2] = 0, afbrydelsesniveau 0. pc, program counter, sættes til startadressen på brugerprocessen. gp, global pointer, sættes ligeledes til startadressen på brugerprocessen. Blandt de 30 registre sættes pv til startadressen på brugerprocessen, da kaldkonventionerne siger, at pv altid indeholder adressen på den funktion, der udføres. Så er alt klart til at sætte processen i gang. Først skrives brugerstakpegeren til usp-registeret med kaldet wrusp, og derefter kaldes KFirst, der genetablerer de 30 registre fra stakken, hvorefter der returneres til brugertilstand med PAL RTI-kaldet. 3.3 Skedulering Et af kravene i opgaven er at, kernen skal understøtte round-robin skedulering på32prioritetsniveauer. En måde at at gøre dette på ville være at oprette en kø for hvert prioritetsniveau. En anden måde (og den vi har valgt) ville være kun at oprette en kø, hvor processerne var sorteret efter prioritet med processer med den højeste prioritet liggende forrest i køen. Hvis man vælger at implementere en løsning med en kø for hvert prioritetsniveau vil man typisk have et array med 32 pegere; 1 for hvert niveau. Der er fordele og ulemper ved begge former for implementation: Ved indsættelse har implementationen med de 32 køer en fordel, idet indsætning sker i 11

12 3.4 Ældning 3 AFVIKLING AF PROCESSER konstant tid. I implementationen med kun en kø vil denne operation have lineær udførelsestid. Når der skal hentes elementer fra de respektive køer vil køen med de 32 niveauer være langsommere end den anden implementation, der umiddelbart kan hente det rigtige element. Ved ældning vil implementationen med de 32 køer skulle flytte pegerne for alle niveauer undtagen det højeste. For det højeste niveau gælder at elementerne fra det næsthøjeste niveau må sættes ind i køen for det højeste niveau. Køretiden bliver da summen af den tid det tager at flytte pegerne og den tid det tager at indsætte de ovennævnte elementer. For implementationen med en kø vil ældning have lineær køretid. Udover de betragtninger, der angår køretid har vi også valgt at inddrage andre faktorer med ind i vores overvejelser for valg af køstruktur. En implementation, der kun består af en kø er væsentlig nemmere at overskue end en med 32 niveauer, som er sværere at holde styr på. En meget stor fordel ved vores implementation er, at vi kan genbruge vores køstruktur i når vi sætter processer i en ventekø. Vi har ment at fordelene er i overtal og derfor har vi valgt en implementation medenkø. I forbindelse med processkedulering vil det være naturligt at overveje, hvordan processer der involverer I/O skal håndteres. Vi har valgt at lade kernen afvikle processer, der involverer I/O så hurtigt som muligt. Der er to hovedårsager til at vi har truffet dette valg. For det første vil I/O-operationer typisk direkte involvere brugere af systemet. F.eks. må man formode at en bruger, har et udtalt ønske om at det tegn han/hun taster ind via tastaturet dukker op på skærmen indenfor et rimeligt tidsrum. Den anden grund er af mere teknisk karakter. Da der som oftest bruges en buffer i forbindelse med I/O-operationer, vil det være hensigtsmæssigt at sørge for at tømme denne buffer, så man undgår at data går tabt. 3.4 Ældning Vi har implementeret ældning i kernen og det fungerer på følgende måde. Hver process har en priotitet, som er den prioritet der angiver processens nuværende prioritet. I kernen findes en funktion KAging, som sørger for at ælde processer. Den måde vores kerne gør det på er ved checke om processerne har ventet over den tid vi har vedtaget at en process skal vente (symboliseret af variablen timetoage) før den bliver opprioriteret. Dette check bliver kørt på alle processer undtaget dem der allerede har prioritet 0, da disse ikke kan opprioriteres. Vi har valgt at alle prioritetsniveauer (pånær prioritet 0, som ikke kan opprioriteres) bliver opprioriteret med samme hastighed. Alternativt kunne vi have valgt en model hvor processer med et allerede højt prioritetsniveau bliver opprioriteret hurtigere end dem med lave prioritetsniveauer. Dette kunne man fx. implementere ved at have 2 timeslices, en for processer med en prioritet under 20 og en for resten. Her ville de processer med prioriteren under 20 have en timeslice der var halvt så stor som den anden. Herved bliver de højt prioriterede processor ældet dobbelt så hurtigt som de andre. Når en process bliver opprioriteret bliver den flyttet fremad et skridt i køen 12

13 3.5 Processkift 3 AFVIKLING AF PROCESSER således at den ligger efter de andre processer med dens nye prioritet. Dvs. hvergang vi prioritetsopgraderer processer bliver køen gensorteret. 3.5 Processkift I forbindelse med afbrydelser kan det være nødvendigt at skifte proces. Dette er typisk fornuftigt i forbindelse med I/O-operationer, hvor den ydre enhed ikke er klar. I det tilfælde er der ingen grund til at låse udførelsen af andre processer mens processen venter på adgang til den ydre enhed. I stedet skiftes der til en anden proces, der kan udføre sine instruktioner indtil den ydre enhed er klar, hvorefter der kan skiftes tilbage til den første proces. En anden typisk situation, hvor det er fornuftigt at foretage et processkift, er ved systemkald, der beder om det. Eksempler på dette er sleep, writedata/readdata som allerede nævnt, hvis I/O-enheden ikke er klar og naturligvis yield. I det følgende vil vi bruge yield som udgangspunkt for at forklare mekanismen omkring processkift, fordi yield netop er et kald til kernen om frivilligt processkift. Situationen er den samme for alle typer af afbrydelser, idet vi minder om, at systemkald håndteres på samme måde som afbrydelser. Når en proces kalder yield sættes kædereaktionen, der skifter til kernetilstand, i gang. Læs mere om skift til kernetilstand i afsnittet om kerne- og brugertilstand. Når et processkift skal foretages sker dette i skridt 4, behandling af afbrydelsen. Da der nu er tale om et systemkald er entry-point et for det sat til ent sys, der kalder KSyscallHandler, der finder ud af hvilken type systemkald der er foretaget. KSyscallHandler identificerer, at det systemkald brugerprocessen har kaldt er yield, og KSyscallHandler kalder derfor KPause. KPause er den kernefunktion, hvor igennem alle processkift sker. Selve processkiftet er ganske simpelt. KPause kalder KSelectNewProcess, der sørger for at gemme den gamle proces og vælge en ny proces fra skeduleringen. 13

14 4 AFBRYDELSER 4 Afbrydelser Der er to overordnede formål med dette afsnit. For det første skal det give et kort overblik over de forskellige systemkald. Da nogle systemkald ikke er umiddelbart indlysende har vi i nogle tilfælde tilføjet en mere tilbundsgående beskrivelse. For det andet skal dette afsnit beskrive hvordan kernen forholder sig til afbrydelser fra ydre enheder, herunder indlejrede afbrydelser. 4.1 Systemkald new sem allokerer en tællesemafor initialiserer dens tæller og returnerer en peger til den. I kernen varetages denne funktionalitet af KInitSem, som også sørger for at initialisere en kø til processer, der venter på atfå adgang til semaforen. Da vi må være sikre på kunne udføre denne operation udeleligt, slår vi afbrydelser fra. wait sem kaldes af en proces der ønsker adgang til semaforen.. signal sem kaldes af en proces, når den forlader semaforen. free sem har til opgave at frigive en semafor. Dette kræver blot frigivelse af det lager som semaforen optager. I nogle situationer vil et sådant kald godt kunne give anledning til problemer. Det vil f.eks. være tilfældet hvis der stadig er en proces, som befinder sig en region, der er beskyttet af en semafor, eller hvis der stadig befinder sig processer i den kø der som semaforen indeholder. Det må dog betragtes som en fejl fra brugerens side, hvis en sådan situation opstår, og det er derfor ikke en situation som kernen skal tage højde for. new mutex allokerer en mutex, som fra start af er åben og returnerer en peger til den. Vil typisk blive brugt at sikre en kritisk region. wait mutex kaldes af en proces, der ønsker at få adgang til den kritiske region. signal mutex kaldes af en proces, når den forlader den kritiske region. free mutex frigiver en tidligere allokeret mutex. malloc kaldes med en mængde lager som skal reserveres. For at reservere dette lager kalder den KMalloc som reserverer lageret og returnerer en pointer til placeringen. Læs mere i afsnit2.2. free frigiver et stykke reserveret lager. Det fungerer på denmåde at free kaldes med en pointer til det lager der skal frigives. Denne peger fjerner den først fra listen over det lager som processerne har reserveret og derefter bliver KFree kaldt med pegeren så den kan blive frigivet i lageret. Læs mere i afsnit 2.2. readdata er et systemkald til at læse data fra com-porten. Systemkaldet udføres ved at kalde funktionen KReadLine med en beskrivelse af hvor meget data der skal indlæses. Da det er et krav i rapporten at I/O udføres udeleligt udføres kald til KReadLine i en kritisk region. readpacket håndterer læsning af pakker fra netkortet. writedata er systemkaldet til at skrive data til com-porten. Dette gøres ved at kalde KWriteLine med de data der skal udskrives. Da det er et krav i rapporten at I/O udføres udeleligt udføres kald til KWriteLine i en kritisk region. readline og writeline er alternative måder at udføre I/O fra/til COM-porten. start proc starter en ny proces ved hjælp af KInitProc. exit er det kald en proces kalder når den ønsker at terminere. get priority returnerer en proces prioritet. set priority sætter en proces prioritet. yield kaldes af en funktion når den frivilligt vil afgive sin CPU-tid. Det yi- 14

15 4.2 Ydre enheder og ur 4 AFBRYDELSER eld gør er at sætte den kaldende proces tilbage i KReady-køen ved hjælp af KPause. sleep sætter en proces til at sove i minimum det specificerede tidsrum. Måden den gør det på er at den lægger det specificerede tidsrum til det nuværende tidpunkt og lægge processen i KWait-køen sorteret efter waketime ved hjælp af KPause. halt standser kernen. 4.2 Ydre enheder og ur Udover afbrydelser fra systemkald kan kernen også blive afbrudt af eksterne enheder. Disse afbrydelser kommer enten fra COM-porten eller fra netkortet. Hvis vi bliver afbrudt af COM-porten, er det enten en proces der vil læse eller en proces der vil skrive. Vi kalder derfor KRestartProcess med enten KReadQ eller KWriteQ. Hvis vi bliver afbrudt af netkortet kaldes en afbrydelsesrutine, som sørger for at læsningen foregår korrekt. Hvis vi bliver afbrudt af uret checker vi om en tidsskive er forløbet. Er dette tilfældet sørger vi for gennem kald til først KPause dernæst KSelectNew- Process at få valgt en ny proces. Afbrydes vi af uret skal vi checke om der er processer, der skal ældes, samt om urafbrydelsen giver anledning til processkift. 4.3 Indlejrede afbrydelser Uanset antallet af indlejrede afbrydelser vil vi kun foretage et processkift i forbindelse med den første afbrydelse. I denne forbindelse skal det bemærkes at systemkald også regnes for at være en afbrydelse. For kort at ridse problematikken op ved indlejrede afbrydelser kan man forestille sig følgende situation. I kernetilstand indtræder en afbrydelse fra f.eks. COM-porten. Mens denne afbrydelse bliver behandlet i KInterruptHandler indtræder endnu en afbrydelse fra uret. Hvis vi dernæst vælger at skifte proces som følge af urets afbrydelse vil den afbrydelse som COM-porten forårsager blive skiftet væk sammen med processen. I bedste fald vil afbrydelsen fra COMporten blive gentaget, i værste fald kan man risikere datatab eller gentagelse af data. En anden situation hvor det er nødvendigt at kunne håndtere indlejrede afbrydelser er i de tilfælde hvor to afbrydelser er synkrone. F.eks. kunne man forestille sig, at en afbrydelse fra COM-porten ankom samtidig med en afbrydelse fra uret. I sådanne situationer ville afbrydelser fra COM-porten blive ignoreret hvis man vælger at lade uret foretage processkiftet. Vi må derfor indføre en form for check, der kan afgøre om den afbrydelse vi er i færd med at behandle er indlejret eller ej. For at kunne udføre dette check har vi brug for to informationer. Vi indfører for det første et skifteflag som er en global variabel som angiver om vi er i færd med at behandle en afbrydelse eller ej. Denne variabel sættes hver gang vi behandler en afbrydelse; dvs. den kan sættes i såvel KInterruptHandler som i KSyscallHandler. Derudover må vi kende den værdi som ps-registeret indeholdt inden afbrydelsen indtraf. Når denne information er tilgængelig kan vi se om afbrydelsen indtraf på kerne- eller 15

16 4.3 Indlejrede afbrydelser 4 AFBRYDELSER brugerniveau samt hvilket afbrydelsesniveau der var gældende da afbrydelsen indtraf. 16

17 5 TEST 5 Test Til at teste vores køer har vi lavet en række simple testprogrammer som tester en specifik delmængde af vores implementation. Disse deler alle en funktion kaldet PrintQ der udskriver PID og Prioritet for alle processerne i den kø den bliver kaldt med. Hver proces egenskaber bliver skrevet ud på en linie for sig. 5.1 Test af put I denne test tester vi om vi kan lægge elementer ind i en kø og om de bliver sorteret korrekt efter prioritet. For at gøre dette har vi lavet et testprogram som vi kalder puttest.cc. Dette testprogram er bygget op af følgende elementer: En processtruktur, denne kan man læse mere om i afsnit 2.3. Derefter kommer selve testfuktionen der hedder test put, som ikke tager nogen parametre. Det den gør er at oprette 4 processer (Proces 1 til 4), to med prioritet 8 (process 1 og 4), en med prioritet 7 (process 2) og en med prioritet 9 (process 3). Herudover har vi vores main-funktion som initialiserer køerne samt starter testen. Herunder har vi et skema med testprogrammets vigtigeste operationer samt uddata. Programmet uddata ok? KReadyQ.Put(&p1, p1.priority); Test af Put() KReadyQ.Put(&p2, p2.priority); - KReadyQ.Put(&p3, p3.priority); process 2, 7 ok KReadyQ.Put(&p4, p4.priority); process 1, 8 printq(kreadyq); process 4, 8 process 3, Test af get I denne test tester vi om det er muligt at tage elementer ud af en en kø og om det sker i den korrekte rækkefølge. Vores testprogram til dette hedder gettest.cc. Dette testprogram er bygget op omkring følgende funktioner: En processtruktur, denne kan man læse mere om i afsnit 2.3. En funktion kaldet fill test der fylder køen med elementer. Selve testfuktionen der hedder test put, tager ingen parametre. Det den gør er at oprette 4 processer (Proces 1 til 4), to med prioritet 8 (process 1 og 4), en med prioritet 7 (process 2) og en med prioritet 9 (process 3). Vores test funktion kaldet test get der i en while løkke trækker elementerne i vores kø ud en af gangen i sorteret rækkefølge. Herudover har vi vores main-funktion som initialiserer køerne samt starter testen. Herunder har vi et skema med testprogrammets vigtigeste operationer samt uddata. 17

18 5.3 Test af wake 5 TEST Programmet uddata ok? while (!KReadyQ.isEmpty()) { Test af Get() KCurProc = KReadyQ.Get(); Get pid: 2 printf( Get pid: %d\n, KCurProc->pid); - ok printq(kreadyq); process 1, 8 process 4, 8 process 3, Test af wake Get pid: 1 - process 4, 8 process 3, 9 - Get pid: 4 - process 3, 9 - Get pid: 3 - Køen er tom - I denne test tester vi om det er muligt at lægge processer til at sove og om de bliver genaktiveret på de korrekte tidspunkter. Vores testprogram til dette hedder waketest.cc. Dette test program er bygget op omkring følgende funktioner: En processtruktur, denne kan man læse mere om i afsnit 2.3. En funktion kaldet fill test der fylder køen med elementer. Selve testfuktionen der hedder test put tager ingen parametre. Det den gør er at oprette 4 processer (Proces 1 til 4), to med prioritet 8 (process 1 og 4), en med prioritet 7 (process 2) og en med prioritet 9 (process 3). En funktion kaldet KWake som checker om en proces er klar til at vågne og hvis den er det, sætter den ind i KReady køen igen. Derefter kommer vores egentlige testfunktion kaldet test wake der sætter de to første processer til at sove indtil tiden 5 og den sidste proces til at sove indtil tiden 6. Når den har gjort det inkrementerer den tiden og kalder KWake som så skal genaktivere processerne når deres tid er nået. Herunder har vi et skema med testprogrammets vigtigeste operationer samt uddata. 18

19 5.4 Test af ældning 5 TEST Programmet uddata ok? test fill(); Test af Wake() printf( time %d\n, time); time 0 KWake(); - printq(kreadyq); process 2, 7 KCurProc = KReadyQ.Get(); process 1, 8 printf( Proces %d skal sove til tid=5\n, KCurProc->pid); process 4, 8 KWaitQ.Put(KCurProc, KCurProc->waketime = 5); process 3, 9 KCurProc = KReadyQ.Get(); - printf( Proces %d skal sove til tid=5\n, KCurProc->pid); KWaitQ.Put(KCurProc, KCurProc->waketime = 5); Process 2 skal sove til tid=3 KCurProc = KReadyQ.Get(); Proces 1 skal sove til tid=3 printf( Proces %d skal sove til tid=6\n, KCurProc->pid); Proces 4 skal sove til tid=4 KWaitQ.Put(KCurProc, KCurProc->waketime = 6); - printq(kreadyq); process 3, 9 while (time++ 10) { - printf( time %d\n, time); KWake(); time 1 printq(kreadyq); - process 3, 9 - time 2 - ok process 3, 9 - time 3 - process 2, 7 process 1, 8 process 3, 9 - time 4 - process 2, 7 process 1, 8 process 4, 8 process 3, 9 - time 5 - process 2, 7 process 1, 8 process 4, 8 process 3, Test af ældning I denne test tester vi om det er muligt at ælde processer. Vores test program til dette hedder agetest.cc. Dette testprogram er bygget op 19

20 5.5 Test af KSelectNewProcess 5 TEST omkring følgende funktioner: En processtruktur, denne kan man læse mere om i afsnit 2.3. En funktion kaldet fill test der fylder køen med elementer. Selve testfuktionen der hedder test put tager ingen parametre. Det den gør er at oprette 4 processer (Proces 1 til 4), to med prioritet 8 (process 1 og 4), en med prioritet 7 (process 2) og en med prioritet 9 (process 3). Den næste funktion er KAging som udføre ældningen af processer. Funktionen kaldet test ageing er den reelle test funktion der søger for at ældningen bliver udført. Herunder har vi et skema med testprogrammets vigtigeste operationer samt uddata. Programmet uddata ok? void KAging() { Test af aging Process* p = (Process*)KReadyQ.GetHead(); - while(p) { process 2, 6 if (p->order > 0) { process 1, 7 p->order ; process 4, 7 process 3, 8 p = (Process*)KReadyQ.GetNext(p); - process 2, 5 process 1, 6 process 4, 6 void test aging() { process 3, 7 ok test fill(); - KAging(); // Udfør ældning process 2, 4 printq(kreadyq); // Udskriv køen process 1, 5 KAging(); // Udfør ældning process 4, 5 printq(kreadyq); // Udskriv køen processs 3, 6 KAging(); // Udfør ældning - printq(kreadyq); // Udskriv køen 5.5 Test af KSelectNewProcess I denne test tester vi om det er muligt at skifte imellem processer ved hjælp af KSelectNewProcess. Vores testprogram til dette hedder nptest.cc. Dette testprogram er bygget op omkring følgende funktioner: En processtruktur, denne kan man læse mere om i afsnit 2.3. En funktion KAging som udfører ældningen af processer. Funktionen KSelectNewProcess som er den funktion der rent faktisk udfører processkiftet. Funktionen kaldet test KSelectNewProcess er den reelle test funktion der søger for at der bliver oprettet processer samt at KSelectNewProcess bliver kaldt. Herunder har vi et skema med testprogrammets vigtigeste operationer samt uddata. 20

21 5.5 Test af KSelectNewProcess 5 TEST Programmet uddata ok? KReadyQ.Put(&p2, p2.priority); Test af KSelectNewProcess KReadyQ.Put(&p3, p3.priority); - KReadyQ.Put(&p4, p4.priority); process 2, 7 p1.priority = 8; process 4, 8 KCurProc = &p1; process 3, 9 for(inti=0;i 3;i++){ - printq(kreadyq); process 4, 7 ok KSelectNewProcess (KReadyQ, KCurProc->priority); process 3, 8 process 1, 8 - process 3, 7 process 1, 7 process 2, 7-21

22 6 DOKUMENTATION 6 Dokumentation I det følgende findes output af kørsler af de udleverede testprogrammer. 6.1 print test AlphaPC164SX> netload /tftpboot/di030007/print_test Digital Semiconductor DC21143 (0): Initializing Hardware address = f Base-Tx Attempting BOOTP... Loading /tftpboot/di030007/print_test at 0x My IP address: Server IP address: ###### File loaded successfully. Size = 0xEEC0 (61120) AlphaPC164SX> go Executing at 0x Go happy kerne Go lucky 1f er Go happy UART Go lucky udskrift 6.2 net test AlphaPC164SX> netload /tftpboot/di030007/net_test Digital Semiconductor DC21143 (0): Initializing Hardware address = f Base-Tx Attempting BOOTP... Loading /tftpboot/di030007/net_test at 0x My IP address: Server IP address: ###### File loaded successfully. Size = 0xF8A0 (63648) AlphaPC164SX> go Executing at 0x ========== Start nettest ========== Pakke ankom: [...One Ring to rule them all, One Ring to find them, ] Pakke ankom: [...One Ring to bring them all and in the darkness bind them ] Pakke ankom: [...In the Land of Mordor where the Shadows lie.] Pakke ankom: [...ÿ..<..abcdefghijklmnopqrstuvwxyz 0000 abcdefghijklmnopqrstuvwxyz] Pakke ankom: [...ÿ..<..abcdefghijklmnopqrstuvwxyz 0000 abcdefghijklmnopqrstuvwxyz] Pakke ankom: [...The Road goes ever on and on...] Pakke ankom: [...Out from the door where it began..] Pakke ankom: [...ÿ..<..abcdefghijklmnopqrstuvwxyz 0000 abcdefghijklmnopqrstuvwxyz] Pakke ankom: [...Now far ahead the Road has gone,..] Pakke ankom: [...Let others follow it who can!...] Pakke ankom: [...Countdown: T - 1 days, 24 hours, 51 minutes] >> Bruger trykker Esc << Timestamp Data1 Data2 Line (hex) File/Function 0x x x x D kernel/ekerne.cc/kselectnewprocess 0x x x E8 0x E kernel/ekerne.cc/kselectnewprocess 0x x x x kernel/ekerne.cc/ksyscallhandler 0x x x x D kernel/ekerne.cc/kselectnewprocess 0x x x E8 0x E kernel/ekerne.cc/kselectnewprocess 0x x x x kernel/ekerne.cc/ksyscallhandler 0x x x x D kernel/ekerne.cc/kselectnewprocess 0x x x E8 0x E kernel/ekerne.cc/kselectnewprocess 0x x x x kernel/ekerne.cc/ksyscallhandler 0x A 0x x x D kernel/ekerne.cc/kselectnewprocess 0x B 0x x E8 0x E kernel/ekerne.cc/kselectnewprocess 0x C 0x x x kernel/ekerne.cc/ksyscallhandler 0x D 0x x x D kernel/ekerne.cc/kselectnewprocess 0x E 0x x E8 0x E kernel/ekerne.cc/kselectnewprocess 0x F 0x x x kernel/ekerne.cc/kinterrupthandler [ latest entry ] 0x x x kernel/ekerne.cc/kinterrupthandler [rf-interactive. Press? for help.] 22

23 6.3 aging test 6 DOKUMENTATION 6.3 aging test AlphaPC164SX> netload /tftpboot/di030007/aging_test Digital Semiconductor DC21143 (0): Initializing Hardware address = f Base-Tx Attempting BOOTP... Bootp Error, retrying (Press Control-C to abort)... Loading /tftpboot/di030007/aging_test at 0x My IP address: Server IP address: ###### File loaded successfully. Size = 0xF0B0 (61616) AlphaPC164SX> go Executing at 0x Jeg er lav men ikke udsultet :-) 6.4 semaphore test AlphaPC164SX> netload /tftpboot/di030007/semaphore_test Digital Semiconductor DC21143 (0): Initializing Hardware address = f Base-Tx Attempting BOOTP... Loading /tftpboot/di030007/semaphore_test at 0x My IP address: Server IP address: ###### File loaded successfully. Size = 0xF180 (61824) AlphaPC164SX> go Executing at 0x Tillykke det ser ud til at dine semaforer virker 6.5 inherit test AlphaPC164SX> netload /tftpboot/di030007/inherit_test Digital Semiconductor DC21143 (0): Initializing Hardware address = f Base-Tx Attempting BOOTP... Bootp Error, retrying (Press Control-C to abort)... Loading /tftpboot/di030007/inherit_test at 0x My IP address: Server IP address: ###### File loaded successfully. Size = 0xF360 (62304) AlphaPC164SX> go Executing at 0x Lavprioritetsproces arvede fra mig :-) 6.6 process test AlphaPC164SX> netload /tftpboot/di030007/process_test Digital Semiconductor DC21143 (0): Initializing Hardware address = f Base-Tx Attempting BOOTP... Bootp Error, retrying (Press Control-C to abort)... Loading /tftpboot/di030007/process_test at 0x My IP address: Server IP address: ###### File loaded successfully. Size = 0xF0B0 (61616) AlphaPC164SX> go Executing at 0x Antal processer startet i alt:

24 6.7 time test 6 DOKUMENTATION 6.7 time test AlphaPC164SX> netload /tftpboot/di030007/time_test Digital Semiconductor DC21143 (0): Initializing Hardware address = f Base-Tx Attempting BOOTP... Loading /tftpboot/di030007/time_test at 0x My IP address: Server IP address: ###### File loaded successfully. Size = 0xF130 (61744) AlphaPC164SX> go Executing at 0x Process1 og Process2 blev færdige Hvis der benyttes tidsskiver burde det virke nu! Hvis der altså ikke er skabt andre afbrydelser :-) 24

25 7 BILAG 7 Bilag 7.1 Kildekode ekerne.cc #include "ekernelib.h" #include "queues.h" #include "ekerne.h" #include "kinit.h" #include "kmalloc.h" #include "comx.h" #include "rf.h" // --- interne kernedatastrukturer --- const int kernelstacksize = 0x1000; long KHeapSize = 0x200000; long UHeapSize = 0x300000; long* KHeap = (long*)0x600000; long* UHeap = (long*)0x900000; int KReadyToTransmit, KCharIsReceived, KPacketReceived, KProcShift; char KReceivedChar; // Den tæller vi bruger som ur unsigned long time = 1; // En global tæller, der giver hver process et unikt pid ulong pidcounter = 0; // Den periode der går mellem vi tjekker om processernes pririotet s kal opgraderes // Vi benytter også variablen til den tid en process venter før den skal // prioritets opgraderes unsigned long timetoage = 512; //Antal ur afbrydelser der går i mellem vi skifter process unsigned long timeslice = 8; //Vores køer Queue<Process> KReadyQ, KReadQ, KWriteQ, KWaitQ, KDeadQ, KNetReadQ; // Semaforer til at sikre I/O udelelighed KSem* semread; KSem* semwrite; KSem* semnetread; // Konstant til netkortet... Ingen aner hvad den gør godt for MAC MAC_store = MAC_none; // Den process der er aktiv pt. Process* KCurProc; 25

26 7.1 Kildekode 7 BILAG // --- interne kerneprocedurer --- // Tager en process fra en kø og sætter den bagerst i ready køen void KRestartProcess (Queue<Process>& blockedonq, int order) { forbid(); if (!blockedonq.isempty ()) //Hvis køen ikke er tom KReadyQ.Put (blockedonq.get(), order); //Så sæt første elem ent ind i Ready køen permit(); // Primitiv garbage collection void KClean() { while(process* p = (Process*)KDeadQ.Get()) { while(alloc* a = p->allocq.get()) KFree(UHeap, UHeapSize, a->data); KFree(KHeap, KHeapSize, p->kstack); KFree(UHeap, UHeapSize, p->ustack); // Modvirker udsultning void KAging() { Process* p = (Process*)KReadyQ.GetHead(); while(p) { if (p->order > 0) { p->order--; p = (Process*)KReadyQ.GetNext(p); // Flytter processer, der er klar til udførsel til klar-køen void KWake() { // For hver proces i vente-køen while (!KWaitQ.isEmpty()) { Process* p = KWaitQ.Get(); // Hvis processen er klar til at vågne, så læg den i klar-k øen if (p->waketime <= time) KReadyQ.Put(p, p->priority); else { // ellers tilbage i vente-køen KWaitQ.Put(p, p->waketime); // Da vente-køen er sorteret ved vi, at efterfølgend e elementer heller ikke er klar til at vågne. break; 26

27 7.1 Kildekode 7 BILAG // Returnerer en ny proces ksp. Kaldes fra KPause extern "C" Registers* KSelectNewProcess (Registers* sp, Queue<Proces s>& blockon, int order) { rf_log(0,0); // Vi skifter proces rf_log(kcurproc->pid,kcurproc->usp); // Vis hvilken proces // Gemmer den gamle proces ksp og usp og læg den ind i skedulerin gen KCurProc->ksp = sp; KCurProc->usp = (void*)rdusp(); blockon.put (KCurProc, KCurProc->priority); // Se om der er en process i KWaitQ der er klar til at blive kørt KWake(); // Se om der er døde processer, der skal ryddes op efter. KClean(); d // Se om det er på tide at udføre ældning if (time % timetoage == 0) { // Hver gang der er gået timetoage ti KAging(); // Udfør ældning af processerne KCurProc = KReadyQ.Get (); // Vælg en ny proces wrusp(kcurproc->usp); // Hvis denne proces køres for første gang... if (KCurProc->lastTime == 0) { // Så skal vi returnere med PAL_RTI KCurProc->lastTime = time; //Sæt lasttime til den nuværende tid KFirst(KCurProc->ksp); KCurProc->lastTime = time; // Marker, at processen bliver kørt nu // KCurProc->order = KCurProc->priority; // Sorter efter priorite ten return KCurProc->ksp; // Returner den nye proces ksp void KInitProc (void (*startaddr) (), ulong userstacksize, ulong pri =16) { rf_log(1,0); // Opret processen Process* proc = (Process*)KMalloc(KHeap, KHeapSize, sizeof(process )); // Reserver lager til kernestakken for denne proces 27

28 7.1 Kildekode 7 BILAG proc->kstack = KMalloc(KHeap, KHeapSize, kernelstacksize); // Gør plads til 30 registre + PAL-stakrammen proc->ksp = (Registers*) ((ulong)proc->kstack + kernelstacksize - sizeof(registers)); // Sæt usp til det allokerede lager proc->ustack = KMalloc(UHeap, UHeapSize, userstacksize); proc->usp = (void*)((ulong)proc->ustack + userstacksize); // Initialiser køen til efterfølgende allokeret lager proc->allocq.init(); // Marker, at processen ikke har kørt før proc->lasttime = 0; // Sæt prioriteten proc->priority = pri; // Opret stakrammen proc->ksp->r[27] = (unsigned long)startaddr; // Sætter register pv til startaddr proc->ksp->ps = 8; proc->ksp->pc = (unsigned long)startaddr; proc->ksp->gp = (unsigned long)startaddr; proc->pid = pidcounter++; KReadyQ.Put (proc, proc->priority); //Læg processen i KReady køen // --- implementation af kernekald --- void KInitSem (KSem* sem, int i, bool m) { int ipl = forbid(); // Slå afbrydelser fra sem->queue.init (); // initialiser køen sem->mutex = m; // Er det en binaer semafor true/false sem->value = i; // Venter permit(ipl); // Slå afbrydelser til igen void KWait (KSem* sem) { int ipl = forbid(); // Slå afbrydelser fra rf_log(5,0); if (sem->mutex){ // Er det en binaer semafor true/false if (sem->value == 1) { // Er der en process i den kritiske region? 1 == nej rf_log(5, 1); sem->value = 0; // Jamen så er der en i den nu sem->kcursem = KCurProc; // Sæt den nuværende semafo r til den nuværende process else { // Ok den kritiske region var optaget så processen skal på semafor køen 28

29 7.1 Kildekode 7 BILAG rf_log(5, 2); // Er den nuværende proces prioritet større end pri oriteten på processen i den kritiske region if (sem->kcursem->priority > KCurProc->priority) { rf_log(5, 3); // Opprioriter den process der har den kritiske re gion sem->kcursem->priority = KCurProc->priority; // Find den i KReadyQ og læg den rigtigt Process* p = (Process*)KReadyQ.GetHead(); while(p) { if (p == sem->kcursem) { KReadyQ.Delete(p); KReadyQ.Put(p, p->priority); break; p = (Process*)KReadyQ.GetNext(p); // Læg KCurProc på semafor køen og vælg en ny. Dette sker ved hjælp af KPause KPause (&(sem->queue), KCurProc->priority); else {//ellers er det en tællesemafor if (!sem->value) KPause (&(sem->queue), KCurProc->priority); //Læg KC urproc på semafor køen og vælg en ny. Dette sker ved hjælp af KPause else sem->value--; //ellers tæl ventende ned permit(ipl); // Slå afbrydelser til igen void KSignal (KSem* sem) { int ipl = forbid(); // Slå afbrydelser fra if (!sem->queue.isempty ()) // Hvis køen ikke er tom KRestartProcess (sem->queue, ((Process*)sem->queue.GetHead( ))->priority); // Så start den næste process fra semkøen else { if (sem->mutex) // Uanset hvor meget der bliver signaleret på en mutex, så forbliver value = 1) sem->value = 1; else sem->value++; // ellers gør plads til endnu en i den kritiske region permit(ipl); // Slå afbrydelser til igen 29

30 7.1 Kildekode 7 BILAG // KReadChar læser et tegn, hvis der er skrevet et, ellers sættes pr ocessen der vil læse til at vente. char KReadChar () { forbid(); if (!KCharIsReceived) // Er der ikke skrevet et tegn? KPause (&KReadQ, 0); // Så sæt processen til at vente KCharIsReceived = 0; // Der er jo skrevet et tegn. KWriteChar (KReceivedChar); //Kald KWriteChar med den modtagne cha r som argument permit(); return KReceivedChar; // returner den modtagne char // KReadChar læser et tegn, hvis der er skrevet et, ellers sættes pr ocessen der vil læse til at vente. int KNetReadBuf (unsigned char* netbuffer, int netbuffersize, MAC* s rc, MAC* dst) { forbid(); KWait(semNetRead); if (!KPacketReceived) // Er der ikke kommet en pakke KPause (&KNetReadQ, 0); // Så sæt processen til at vente KPacketReceived = 0; // Der er jo skrevet et tegn. KSignal(semNetRead); permit(); return edev_receive_packet (&i82595, netbuffer, netbuffersize, src, dst); void KWriteChar (char ch) { forbid(); if (!KReadyToTransmit)//Hvis vi ikke kan skrive KPause (&KWriteQ, 0); //Så sæt processen i vente køen KReadyToTransmit = 0; //set KReadyToTransmit til 0 wrio (com1thr, ch); //Skriv ch (funktionens argument) til com 1 if (ch == \r ) KWriteChar ( \n ); //Hvis ch er \r så skriv \n ud (newline) permit(); long KReadLine (char* p, int max) { KWait(semRead); long res = 0; for (int i = 0; i < max-1; i++){ //Så længe slutningen af linien i kke er nået res++; if ((*p++ = KReadChar ()) == \r ) // og det læste tegn ikk e er vognretur; læs næste tegn break; // ellers afbryd *p = \0 ; // og nulterminer 30