Tentamen Lösningar EDA698 Realtidssystem

LUNDS TEKNISKA HÖGSKOLA 1(7) Institutionen för datavetenskap Tentamen Lösningar EDA698 Realtidssystem 13 10 22, 14:00 19:00 1. Prioriteter, korrekthet a) Realtidsproblemet kvarstår. Det finns ingen garanti att problemet inte uppstår igen. Programmet måste uppfyller både korrekthetskraven (concurrency OCH realtime) oberoende av varandra. b) Till exempel: en högprioriterad styrtråd till en robot kombinerad med en lågprioriterad dataloggningstråd. c) En kritisk sekvens är ett kodavsnitt som är skyddat mot datakorruption, kapplöpning, etc., vanligen genom användning av en synkroniseringsprimitiv som ej tillåter samtidig trådaccess till kodavsnittet (i.e. mutex-semafor). d) Använd synkroniseringsprimitiver! Semafor, monitor, mailbox. (Gärna med lite mera förklaring, såklart). 2. Dödlägesanalys Resursallokeringsgraf: A B M1 M2 M3 C C Grafen visar att dödläge kan uppstå på två ställen (sträckad, prickad). Byt anropen från tråd C genom att låta metoden m1.c1() anropa m2.c4() istf tvärtom. Sedan kan tråd C anropa m1.c1() och därmed få samma hold-wait-ordning mellan M1 och M2 som tråd A, och båda cirklar försvinner. Visas med fördel i en ny graf. Båda cirklar måste utpekas och lösningen måste ta hänsyn till båda fallen för full poäng. 3. Avbrottshantering, kontextbyte

2(7) 1. Aktiviteterna (koden) man skriver kan vid exekvering bli avbruten i princip var och när som helst, t o m mitt under exekveringen av en enkel rad kod. Det innebär också att exekveringen av en kritisk sekvens kan avbrytas och pausas under en viss tid, tråden kan dock inte bli tvungen att lämna resursen till någon annan tråd (pre-emptive scheduling innebär inte med automatik resource pre-emption). 2. Följande lista var förväntat: Turn off interrupts Push PC, then CPU registers on stack Save Save stack pointer in process record Get new process record and restore stack pointer from it Switch Pop CPU registers, then PC from stack Turn on interrupts Restore 4. Schemaläggningsanalys, Liu & Layland a) C i : värstafallsexekveringstid för tråd i. T i : periodtid för tråd i. n: antal trådar i systemet. b) Enbart periodiska trådar, ingen blockering, deadline=period, fixprioritetsschemaläggning (RMS). c) 1. Systemet är schemaläggningsbart. 2. Systemet är kanske schemaläggningsbart och kräver exakt analys. 5. Schemaläggningsanalys, RMS Blockeringstider: B D = 0 (lägst prioritet) B C = d = 5 (indirekt blockering) B B = d + c = 9 (indirekt + direkt) B A = d + max(b, c) = 9 (direkt+direkt) Responstider: R A = 3 + 9 = 12 R B = 9 = 13 R B = 13 + 13 3 = 16 R B = 13 + 16 3 = 19 R B = 13 + 19 3 = 19 R C = 5 + 5 = 10 R C = 10 + 10 3 + 10 4 = 17 R C = 10 + 17 3 + 17 4 = R C = 10 + 3 + 4 = R D = 6 R D = 6 + 6 3 + 6 6 5 = 18 R D = 6 + 18 3 + 18 R D = 6 + 21 3 + 21 R D = 6 + 3 + 18 21 5 = 21 5 = 5 = Alla responstider är lägre än korresponderande periodtid. Systemet är schemaläggningsbart.

3(7) 6. Programmering public class BurgerShelf { private HW myhw; private int id; // id-number for shelf private int shelfsize; // number of burgers the shelf can take private int maxtime; // maximum time for a burger in the shelf (in seconds) // -------------- Task part a) ---------------- // stuff for the ring buffer private int currentnumofburgers; private int[] burgertimes; private int nexttoput, nexttoget; // number of old (bad) burgers private int badburgers; // for convenience private int margintime; private int oldestburgertimestamp; /** Constructor for a burger shelf */ public BurgerShelf(HW hw, int shelfsize, int maxsecondsonshelf) { this.myhw = hw; this.id = myhw.getshelfid(); this.shelfsize = shelfsize; this.maxtime = maxsecondsonshelf; // -------------- Task part a) ---------------- // INIT YOUR ATTRIBUTES HERE burgertimes = new int[ shelfsize]; currentnumofburgers = 0; nexttoput = 0; nexttoget = 0; badburgers = 0; margintime = (int)(maxtime*0.); oldestburgertimestamp = 0; Viktigt här: det måste till något attribut för lagring av burgarnas tider (antingen när de kom in, hur länge de får ligga kvar, eller hur länge de har legat i banan; bäst är det förstnämnda, det blir minst omräkning), och man måste på något sätt hålla antalet för gamla burgare uppdaterat. En ringbuffer är ett vanligt array med roterande indices för första och sista, vilket gör det enkelt att lägga till eller plocka bort utan att skifta alla element upp eller ner. Jfr övning 1. // -------------- Task part a) ---------------- // WRITE YOUR METHODS HERE public synchronized void putburger( int timestamp) { while( currentnumofburgers >= shelfsize) wait(); // not necessary if( currentnumofburgers == 0) { oldestburgertimestamp = timestamp; notifyall(); //not necessary, but if there is a block on empty shelf, it is better to have currentnumofburgers++; burgertimes[ nexttoput] = timestamp;

4(7) if( ++nexttoput == shelfsize) nexttoput = 0; Viktigt här: synchronized. Spara undan tidstämpeln på det tänkta sättet, dvs hanteringen av den valda datastrukturen måste vara korrekt. public synchronized void removeburger() { while( currentnumofburgers == 0) wait(); // not necessary with reliable hardware if( currentnumofburgers == shelfsize) notifyall(); // not necessary if( badburgers > 0) { badburgers--; myhw.display( "Throw away " + badburgers + "!"); if( badburgers == 0) myhw.stopalarm(); currentnumofburgers--; burgertimes[nexttoget] = -1; if( ++nexttoget == shelfsize) nexttoget = 0; // convenience attribute handling, not necessary if( currentnumofburgers > 0) oldestburgertimestamp = burgertimes[nexttoget]; Viktigt här: synchronized. Hanteringen av gamla burgare; om man tar ut en burgare och det fanns någon gammal, är den som tas bort en gammal burgare. Enbart om antal gamla burgare blir 0 efter borttagningen, ska larmet stängas av. Om det fanns minst en gammal burgare, ska displayen uppdateras, och får evtl visa att 0 burgare ska tas bort. Iom att metoden måste vara synchronized, vilket också checkburgers måste vara, är uppdateringen av displayen möjligt från båda hållen. Ta bort tidstämpeln av den borttagna (äldsta) burgaren på det tänkta sättet, dvs hanteringen av den valda datastrukturen måste vara korrekt. Det är ok att anta att uppdateringen av displayen ifall det inte fanns gamla burgare sköts med nästa anrop av checkburgers, det går såklart också bra att göra den uppdateringen direkt här, när en ny äldsta burgare kommer fram i banan. public synchronized void startalarm() { while( badburgers == 0) wait(); Viktigt här: synchronized (man läser ut värdet av ett attribut). While - wait med rätt villkor. INGET anrop till doalarm, eftersom den då blockerar tråden i en synchronized metod i monitorn och systemet låser sig! public synchronized void checkburgers() { int time = myhw.time(); if( currentnumofburgers > badburgers && (badburgers > 0 time - oldestburgertimestamp >= maxtime)) { if( badburgers == 0) notifyall(); // this one IS necessary! int checkind = nexttoget + badburgers; if( checkind == shelfsize) checkind = 0; while( checkind!= nexttoput && time - burgertimes[checkind] + margintime >= maxtime) { badburgers++; checkind++; if( checkind == shelfsize) checkind = 0; if( badburgers > 0) myhw.display( "Throw away " + badburgers + "!"); else if( badburgers == 0 && currentnumofburgers > 0)

5(7) myhw.display( "Time until first burger goes bad: " + (maxtime - (myhw.time()-oldestburgertimestamp))); else if( currentnumofburgers == 0) myhw.display( ""); // end of class BurgerShelf Viktigt här: synchronized. Tidskontroll på första burgaren och följande kontroll enligt marginaltiden på andra burgare. Uppdatering av gamla burgare när det redan finns sådana, dvs kontroll från första burgaren som tidigare INTE varit upptäckt som gammal, men nu faller under marginaltiden. Notify ifall antal gamla burgare går från 0 till något större, för att väcka alarm-tråden. Allmän notify är ok, om än inte nödvändig. // -------------- Task part b) ---------------- // WRITE YOUR "RUN" METHODS HERE public class BurgerInHandler extends Thread { public BurgerInHandler( BurgerShelf bs, HW hw) { while(true) { shw.inputdetected(); bs.putburger(shw.time()); // end of class BurgerInHandler public class BurgerOutHandler extends Thread { public BurgerOutHandler( BurgerShelf bs, HW hw) { while(true) { shw.removaldetected(); bs.removeburger(); // end of class BurgerOutHandler public class AlarmStartHandler extends Thread { public AlarmStartHandler( BurgerShelf bs, HW hw) {

6(7) while(true) { bs.startalarm() shw.doalarm(); // end of class AlarmStartHandler Viktigt här: Någon form av loop (while(true) går bra, while(!isinterrupted()) också). Korrekt sekvens i anropen, dvs. anropa den blockerande metoden i hårdvaran (eller i monitorn för larmet), sedan, när den returnerar, alltså tråden väcks, anrop till den registrerande metoden i monitorn, eller (för larmet) den utförande (i sin tur blockerande) monitor. Var det fel i monitorn med blockerande anrop till hårdvaru-metoderna, men på rätt ställe i sekvensen, och trådarna hade utifrån detta konsistenta anrop till monitorn, drogs det inte ytterligare någon poäng här. public class BurgerWatchDog extends Thread { public BurgerWatchDog( BurgerShelf bs, HW hw) { int t, tdiff; t = shw.time(); while( true) { bs.checkburgers(); t += 10; // if counting in seconds (using time()) tdiff = t - shw.time(); if( tdiff > 0) sleep( tdiff * 1000); // end of class BurgerWatchDog Viktigt här: Korrekt loop med tidsuppdatering utan drift, korrekt anrop till sleep (i ms!) och korrekt anrop till checkburgers. public class BurgerCabinet { // -------------- Task part c) ---------------- // WRITE YOUR METHOD HERE public static void main(string[] args) { int numshelf = 2; HW[] thehw = new HW[numShelf]; BurgerShelf[] shelf = new BurgerShelf[numShelf]; BurgerInHandler[] inh = new BurgerInHandler[numShelf]; BurgerOutHandler[] outh = new BurgerOutHandler[numShelf]; AlarmStartHandler[] ash = new AlarmStartHandler[numShelf]; BurgerWatchDog[] wd = new BurgerWatchDog[numShelf]; thehw[0] = new HW(); // one possible assumption thehw[1] = new HW();

7(7) shelf[0] = new BurgerShelf( thehw[0], 7, 5*60); shelf[1] = new BurgerShelf( thehw[1], 7, 3*60); for( int i = 0; i<numshelf; i++) { inh[i] = new BurgerInHandler( shelf[i], thehw[i]); outh[i] = new BurgerOutHandler( shelf[i], thehw[i]); ash[i] = new AlarmStartHandler( shelf[i], thehw[i]); wd[i] = new BurgerWatchDog( shelf[i], thehw[i]); inh[i].start(); outh[i].start(); ash[i].start(); wd[i].start(); // end of class BurgerCabinet Viktigt här: Det behövs två instanser av HW. Det var ok att anta vilken konstruktor som helst, bara det blev en instans till varje hylla. Korrekta anrop till alla konstruktorer samt anrop till start() för alla trådinstanser. 7. Design Väldigt kortfattad skiss: Displayen som ska visas för kökspersonalen kan hanteras utifrån informationen i BurgerShelfmonitorn, som måste då också innehålla bör-värdet för antalet burgare i banan. Varje BurgerShelf får ansvar för en egen burgaretyp, vilket i princip redan antyds med uppgift 6 c), då man skulle skapa två hyllbanor med olika tidsperioder. Typbeteckningen kan man tänka sig som ett extra attribut, så att man enkelt kan visa vilken typ av burgare som ska lagas och inte bara "hylla 3 behöver 4 burgare till". Man kan tänka sig att sammanfatta flera BurgerShelfmonitorer i en BurgerCabinet som har koll på vilken bana som är den relevanta vid en viss tidspunkt. Det måste till någon övervakningstråd och en sensor (eller en kölappsliknande lösning) för kunder som kommer in (likt BurgerInHandler). Här måste dock till någon monitor för beställningar och kundhantering (en väntekö-monitor helt enkelt) som hanterar också beräkningar samt matchar uppskattningar mot beställningar. Kassorna borde då få hanteringstrådar på sig, som matar in sina beställningsinformationer till den nya beräkningsmonitorn. Vid ändringar i antalet förväntade burgare i en bana måste då ytterligare en matchande hanteringstråd mata den informationen i den bestående, matchande BurgerShelf-monitorn för hanteringen av det nya bör-värdet (i jämförelse till vad som finns redan i hyllan). Man kan aldrig veta om en person som ställer sig i kön ska lämna en beställning till enbart sig själv eller om det blir till en familj eller t o m större grupp som väntar ute. Det är en faktor som inte går att ta hänsyn till, och kunden måste veta om det. Uppskattningarna kan aldrig bli bättre (mindre osäker) än värden man stoppar in!