Tentamen EDA698 Realtidssystem (Helsingborg)

Transkript

1 LUNDS TEKNISKA HÖGSKOLA 1(10) Institutionen för datavetenskap Tentamen EDA698 Realtidssystem (Helsingborg) , Det är tillåtet att använda Java snabbreferens och miniräknare, samt ordbok. Det går bra att använda både engelska och svenska uttryck för svaren. Den här tentamen består av två delar: teori, frågor 1-5 (24 poäng), och programmering & design, frågor 6 och 7 (16 poäng). För godkänd (betyg 3) krävs sammanlagt ca hälften av alla 40 möjliga poäng samt att det krävs ca en tredjedel av poängen i varje del för sig. För högsta betyg (5) krävs dessutom att en del av poängen uppnås med (del)lösningar till båda uppgifterna i programmering & design (preliminärt). 1. Jämnlöpande exekvering, delade resurser och synkronisering a) I ett flertrådigt system, då minst två trådar ska arbeta med samma data resurs, kan det uppstå ett problem med inkonsistent data. Vad menas med det? Förklara med ett litet konkret exempel! Hur kan man i allmänhet förhindra sådana inkonsistenta tillstånd? Ge ett övergripande begrepp på vad som måste uppnås! b) I kursen diskuterades tre konkreta mekanismer som man kan använda för att få till säker kommunikation och resursdelning mellan flera trådar i ett system. Lista och förklara dessa mekanismer med någon mening var. Är de likvärdiga? Förklara varför! c) Förklara följande diagrammet! Vad är det som diagrammet föreställer, vad är det som händer i de olika delarna? synchronized wait notify < 2 #6./ 3#1 45 #+ #6 # synchronized(.){ * & & wait notify * &# * & & & ()(!!"# "! D (2p + 4p + 3p)

2 2(10) 2. Dödlägesanalys Staden ska få ett litet service järnvägssystem, dels för nöjes skull och dels för att underlätta lite för de som har svårt att gå att ta sig runt stadskärnan. Eftersom man trots allt ska hålla kostnaderna nere, beslutar man att helt enkelt ha ett enkelspårigt ringsystem, där tågen enbart ska serva hållplatserna åt ett håll. Folk får helt enkelt åka runt stadskärnan lite då och då. För att det inte ska bli alltför långa resor tillåter man dock två extra spår, så att man får ett rälssystem som i bilden, med rälsavsnitt A till F (med motsvarande hållplatser), där av säkerhetsskäl enbart ett tåg kan vara på varje avsnitt vid en given tidpunkt, dvs varje avsnitt fungerar som en delad resurs med ömsesidig uteslutning. För att ett tåg ska kunna komma från ett avsnitt till ett annat måste alltså föreliggande avsnittet vara ledigt (signalen slår om till grönt ljus då), dvs ett tåg blockerar (håller) ett avsnitt medan det väntar på ett annat. Tågen ska ha fasta körsträckor som alltid täcker samma sekvens, dvs för att alla hållplatser ska servas måste tågen få olika typer som tillhör körsträckorna. Det finns fyra tågtyper T1, T2, T3, T4, som har följande sträckor: T1 - ABDEA, T2 - ACDFA, T3 - ABDFA och T4 - ACDEA. Det är uppenbart att man måste ha minst två tågtyper för att nå alla hållplatser, antingen T1 och T2 eller T3 och T4. Nu gäller det alltså att optimera antalet och tågtyper så att rälsen utnyttjas maximalt, och trafikanterna inte behöver vänta alltför länge på ett passande tåg, så man börjar testa lite olika lösningar. a) En första belastningsanalys ska göras, där man accepterar att man inte når alla hållplatserna, dvs man räknar enbart med tåg av en typ. Varför är det maximalt tre tåg av samma typ som man kan ha i gång? Förklara med hjälp av en resursallokeringsgraf för tåg av typ T1 (ett tåg motsvarar en tråd och ett rälsavsnitt en delad resurs)! b) Man inser lätt att det går alldeles utmärkt att ha ett tåg T1 och ett tåg T2, som då ser till att man kan åka från och till alla hållplatser. Visa med hjälp av en utökad resursallokeringsgraf, som nu tar hänsyn till två tågtyper T1 och T2, att det skulle fungera! c) Nackdelen av att ha enbart två tåg körandes är att man måste byta tåg ibland, t ex för att åka från B till F, och att det då tar lite tid tills det andra tåget kommer, eftersom det enbart är två tåg som kör. Testfolket bestämmer sig för att prova med två tåg av varje typ, dvs två tåg T1 och två tåg T2. Det går bra en stund, sen hamnar de i ett dödläge. Förklara detta fenomen med hjälp av din resursallokeringsgraf och några meningar. d) Trots detta bakslaget fortsätter man att testa och lyckas till slut hitta ett sätt att ha fyra tåg igång. Vilket sätt är det och fungerar det alltid? (Tips: Ta en ännu mera utökad resursallokeringsgraf som underlag!) 3. Prioriteter D E F C B A (1p + 1p + 2p + 1p) a) Vad är prioritetsinvertering (priority inversion)? Förklara med hjälp av en figur och några meningar. b) Varför får prioritetsinvertering ej förekomma i ett system som ska uppfylla realtidskrav? c) Vad kan man göra för att undvika detta problem? Förklara, motivera ditt svar! (1p + 1p + 1p) 4. Schemaläggning (scheduling) Man kan schemalägga ett flertrådigt system antingen statiskt eller dynamiskt. Förklara dessa två typer av schemaläggning och diskutera för- och nackdelar! (2p)

3 3(10) 5. Schemaläggningsanalys Givet är ett system med trådarna A, B och C, som kommunicerar genom tre monitorer M1, M2 och M3 enligt metodanropen beskrivna i grafen nedan. Annan kommunikation eller synkronisering mellan trådarna förekommer inte. Tabellen nedan visar exekveringstiderna (i värsta fall, WCET) C i och perioderna T i för alla trådar i millisekunder. Schemaläggningen sker dynamiskt enligt RMS och det används dynamiskt prioritetsarv (basic priority inheritance). Formeln för svarstider är: R R k+1 k i = C i + B i + i C T j j hp(i) j Blockeringsgraf för systemet: M1 Trådarnas perioder och exekveringstider: a1(); 30ms A b1(); 50ms B T C A B C a3(); 60ms b2(); 30ms M3 M2 Formeln av Liu & Layland: c3(); 105ms C c2(); 20ms C i T i < n(2 1 n 1) a) Med formeln av Liu & Layland (se ovan) kan man få en första uppskattning om ett tänkt system går att schemalägga. Ange formeln och förklara, varför detta INTE är en lämplig metod för det här givna systemet! Vad måste alltså visas för det givna systemet? b) Beräkna blockeringstiderna B i! c) Analysera systemet med en exakt metod! Är det schemaläggningsbart? 6. Programmering Parkeringshus (2p + 1p + 2p) Stadens parkeringshus ska byggas om så att det äntligen blir en bra reglering av in- och utsläpp av bilar och ingen kör in förgäves när det egentligen inte finns plats. Dessutom vill stadsförvaltningen ha lite bättre statistik över antalet bilar som står parkerade under dygnet. Parkeringshuset är rätt litet och har enbart en in- och utfart med respektive bommar. När man kommer till infarten får man en biljett utskriven som har ankomsttiden sparad. Innan man lämnar parkeringen matar man in biljetten i en kassa-automat som läser av parkeringstiden, tar betalt och sparar betaltidpunkten på biljetten. Man har nu en viss tid på sig att leta upp bilen och köra fram till utfartens bom. Där matar man in biljetten i läsaren och har biljetten betalts samt att inte tidsmarginalen överskridits öppnas bommen och man kan köra ut. Annars kommer biljetten ut igen och ett meddelande visas. Betalningshanteringen fungerar redan bra, den behöver inte tänkas på. Staden har dock följande krav på den nya styrningen av in- och utsläpp: Hantering av in- och utpassage ska vara oberoende av varandra, dvs samtidigt som en bil håller på att checkas in kan andra bilar köra ut.

4 4(10) Om parkeringshuset är fullt, ska ingen biljett skrivas ut till en bilförare som trycker på knappen, man får vänta helt enkelt (eller ge upp). Har det varit fullt och en bil körs ut, måste en eventuellt väntande bilförare trycka på knappen igen, innan en biljett skrivs ut. Efter att bilföraren har tagit biljetten, öppnas bommen. När bilen börjar passera bommen, registreras detta med hjälp av en ljusstråle som bryts. Först när bilen har passerat ljusstrålen, dvs den är inte bruten längre, ska den fysiska bommen stängas. Vid utpassage ska den fysiska bommen öppnas efter att biljetten har kontrollerats och godkänts (betalt och ingen tidsmarginal har överskridits), sen är det samma teknik som för inpassage, dvs en ljusstråle används för att säkerställa att bilen har passerat innan bommen kan stängas igen. Antalet bilar i parkeringshuset ska räknas upp när bilen har passerat infartsbommen efter biljettutskrivning. Antalet bilar i parkeringshuset ska räknas ner när bilen har passerat utfartsbommen efter biljettkontroll. Parkeringshuset är öppet mellan kl 6:00 och kl 24:00. Under den tidsperioden ska antalet parkerade bilar rapporteras varje kvart för statistiken. Öppettiderna ska övervakas av infartshanteringen; den ska stängas först när det blir stängningsdags. Styrsystemet stängs av under natten och initialiseras på nytt varje dag (dock förblir antalet kvarvarande bilar sparade i en fil), så att det blir möjligt att lätt ändra öppettiderna. Uppgift: För att kunna hantera in- och utfart oberoende behövs två klasser (InGate och OutGate) för kommunikationen mellan knapparna (bilföraren), sensorer och bommarna (beskrivna i klassen Gate, som är superklass till just InGate och OutGate), som används av en motsvarande tråd var (InHandler och OutHandler). För att de ska kunna övervaka antalet bilar behövs en monitorklass (ParkingData) och för rapporteringen av antalet bilar med jämna mellanrum behövs en till tråd (Reporter), som läser av data i monitorn och skriver ut rapporten (det går bra till System.out.println). Slutligen måste allt startas upp och initialiseras via en övergripande Styrningskomponent, klassen ParkingControl (given). Det som behövs nu är att programmera klart resterande delar av styrningssystemet med hjälp av kod-skeletten (Appendix A), specifikation (se ovan) och lämpliga Java-metoder (se Appendix B) enligt följande: a) Skriv koden för monitor-metoden carin som räknar upp antalet bilar i parkeringshuset och meddelar att det nu är fullt om det inte var det innan. b) Skriv koden för monitor-metoden carout som räknar ner antalet bilar i parkeringshuset och meddelar att det inte längre är fullt om det var det innan. c) Skriv koden för monitor-metoden checkparkingspace. Den ska blockera så länge parkeringshuset är fullt. d) Skriv koden för monitor-metoden writereport. Den ska skriva ut aktuellt antal bilar i parkeringshuset tillsammans med den aktuella tiden. e) Skriv koden för metoden issueticket i klassen InGate. Den ska blockera tills biljettknappen har tryckts (ticketbuttonpressed == true). Sedan ska den skriva ut en biljett med den aktuella tidsstämpeln (i ms) och dess löpande nummer för dagen (metoden finns redan, men anropet ska du skriva själv). Sedan ska den blockera tills biljetten har tagits från automaten. f) Skriv koden för metoden checkticket i klassen OutGate. Den ska blockera tills en biljett blir inmatad i läsaren (ticketentered == true) och sedan kontrollera att biljetten är betald och tidsmarginalen allowedtime efter betalningstidpunkten inte har överskridits. är det något som är fel, ska biljetten returneras (metoden finns redan, anropet ska du skriva själv) och metoden ska blockera tills biljetten har tagits från läsaren. Är allt i sin ordning, lämnar metoden över tillbaka till anropande tråd efter biljetten kontrollerats.

5 5(10) g) Skriv koden för run-metoden i trådklassen InHandler. Denna ska så länge det inte är stängningsdags och inte parkeringshuset är fullt invänta en knapptryck på biljett-knappen (se InGate, metoden issueticket). Har knappen tryckts ska den vänta på att föraren tagit ut biljetten och öppna bommen. Nu ska den vänta på att passagen av bilen registreras (ljusstråle-avläsning i InGate) och sedan se till att bommen stängs, samt att bilantalet räknas upp i monitorn ParkingData och eventuellt se till att utgångsläget återställs. h) Skriv koden för run-metoden i trådklassen OutHandler. Denna ska invänta en inmatning av en betald biljett (hanteras i OutGate). Är allt ok, ska bommen öppnas, annars ska biljetten returneras (ett felmeddelande visas). Har bommen öppnats, ska den vänta på att passagen av bilen registreras (ljusstråle-avläsning i OutGate) och sedan se till att bommen stängs, samt att bilantalet räknas ner i monitorn ParkingData och eventuellt se till att utgångsläget återställs. Sedan ska den börja om med väntandet. i) Skriv koden för run-metoden i trådklassen Reporter. Den ska med 15 minuters mellanrum se till att det aktuella antalet bilar i parkeringshuset skrivs ut tillsammans med den aktuella tidsstämpeln. (1p + 1p + 1p + 1p + 2p + 2p + 2p + 1p + 1p) 7. Design Parkeringshus med två in-/utfarter och kontrollerat utsläpp Parkeringshuset växer till sig lite och ska få en extra in- och utfart. Dessutom har det upptäckts en miss i planeringen för det ursprungliga systemet: Om någon betalar sin biljett efter kl 23:45 (dvs mindre än en kvart innan parkeringshuset stänger, vilket är tidsmarginalen för utsläpp efter betalningen), kan ju den personen inte utnyttja den kvarten om utfarten stänger kl 24:00 prick. Man bestämmer sig att utfarten ska hållas öppet tills alla biljetter som betalats innan stängning har använts vid någon utfart. Infarterna ska dock stängas som tidigare. Din uppgift är nu att lägga till de delar av systemet som behövs för att hantera dubbla in- och utfarter och den smartare utsläppskontrollen (OBS: du behöver INTE skriva koden, bara göra ett design-förslag), baserad på det befintliga systemet. Beskriv hur DIN lösning skulle kunna se ut. Du kan göra det med en ritning, skriven text, kod-skelett eller en blandning av dessa. Några stödfrågor du kan ställa dig är: Vilka komponenter (trådar, andra klasser) måste läggas till? Får trådklasserna / monitormetoderna extra villkor på sig? Vilka ändringar behövs i hanteringen av insläppet? Hur kan man säkerställa att inte en bilförare vid infart 2 får en biljett utskriven medans sista möjliga bilen håller på att rulla genom infart 1? Hur kan man hantera det nya utsläppsvillkoret? Hur borde man hantera avslutet för trådklassen OutHandler? Vad händer med rapport-tråden, när ska den avslutas? Slut på uppgifterna (Appendix A och B finns på resterande sidor). Lycka till! (4p)

6 6(10) A Koden till uppgift 6 Styrklassen ParkingControl (färdig, inget att ändra) Den här beskrivningen är enbart till för information om hur systemet hänger ihop, här behöver du inte ändra något! Om du behöver, kan du självklart ändra i alla redan skrivna delar, men det borde fungera utan ändringar annat än där du ska skriva koden klart! public class ParkingControl { private InGate in; private OutGate out; private InHandler inhandler; private OutHandler outhandler; private Reporter reporter; private ParkingData parkingdata; private int parkedcars; // Constructor that starts up and closes down the control system. public ParkingControl( long closingtime, long allowedtimeafterpayment, int maxnumofcars, int parkedcars) { this.parkedcars = parkedcars; parkingdata = new ParkingData( maxnumofcars, parkedcars); in = new InGate(); out = new OutGate(); long openingtime = System.currentTimeMillis(); inhandler = new inhandler( openingtime, closingtime, parkingdata, in); outhandler = new OutHandler( allowedtimeafterpayment, parkingdata, out); reporter = new Reporter( parkingdata); inhandler.start(); outhandler.start(); reporter.start(); try { inhandler.join(); // Wait for the handler to terminate itself at closingtime outhandler.interrupt(); reporter.interrupt(); Thread.sleep( 200); // Give them all time to terminate properly catch (InterruptedException exc) { // save the number of cars to be locked in over night // assuming a "getnumber"-method that can be called after the day s run this.parkedcars = parkingdata.getcurrentnumberofcars(); // end of class ParkingControl Monitor-klassen ParkingData (fyra metoder att lägga till) public class ParkingData { private int maxnumcars; private int currentnumcars; private boolean parkingfull; // Add attributes if necessary // Change if necessary

7 7(10) public ParkingData( int maxnumberofcars, int currentnumberofcars) { maxnumcars = maxnumberofcars; currentnumcars = currentnumcars; parkingfull = false; if( currentnumcars >= maxnumcars) parkingfull = true; // end of constructor // Task part a), b), c), and d) // WRITE YOUR METHODS HERE // task part a) // method: carin() // add suitable tags, return value, and parameters! (if needed!) // task part b) // method: carout() // add suitable tags, return value, and parameters! (if needed!) // task part c) // method: checkparkingspace() // add suitable tags, return value, and parameters (if needed!) // task part d) // method: writereport() // add suitable tags, return value, and parameters (if needed!) // end of class ParkingData Hårdvarugränssnittet / klassen Gate (färdig, inget att ändra) public class Gate { //... other attributes, constructor and other stuff for setting / getting values // TRUE, if a car is cutting the light, i.e., the circuit is open private boolean lightcircuitopen; // TRUE, if the gate is open public boolean gateisopen; // opens the physical gate public void opengate() {//... // closes the physical gate public void closegate() {//... //... // end of class Gate Hårdvarugränssnittet / klassen InGate (en metod att lägga till) public class InGate extends Gate { //... other attributes, constructor...

8 8(10) // TRUE, when someone pressed the ticket button // while the keylistener is set to "active" // otherwise FALSE private boolean ticketbuttonpressed; // TRUE, when an issued ticket has been taken out // FALSE, while a printed ticket is waiting in the slot private boolean tickettaken; // sets the hardware key listener active (TRUE) or // inactive (FALSE) public void setkeylistener( boolean active) {//...; // resets the ticket button flag to FALSE public resetticketbuttonflag() {//... // prints a ticket and offers it, sets tickettaken to FALSE public void printticket( int ticketnumber, long timestamp) {//... // Task part e) // task part e) // method: issueticket() // add suitable tags, return value, and parameters (if needed!) // end of class InGate Hårdvarugränssnittet / klassen OutGate (en metod att lägga till) public class OutGate extends Gate { //... other attributes, constructor... // TRUE, when someone feeds in a (paid) ticket private boolean ticketentered; // TRUE, when a rejected ticket has been taken out // FALSE, while a rejected ticket is waiting in the slot private boolean rejectedtickettaken; // returns a ticket and sets rejectedtickettaken to FALSE public void rejectticket() {//... // reads the ticket and returns the time of payment, // or -1 in case it was not paid public long readticket() {//... //resets the ticketentered flag to FALSE after handling the ticket public void resetticketenteredflag() {//... // Task part f) // task part f) // method: checkticket() // add suitable tags, return value, and parameters (if needed!) // end of class OutGate

9 9(10) Trådklassen InHandler (run-metoden måste implementeras) public class InHandler extends Thread { private long openingtime; private long closingtime; private InGate ingate; private ParkingData pdata; public InHandler( long otime, long ctime, InGate in, ParkingData p) { openingtime = otime; closingtime = ctime; pdata = p; ingate = in; // Task part g) public void run() { // WRITE YOUR METHOD HERE // end of class InHandler Trådklassen OutHandler (run-metoden måste implementeras) public class OutHandler extends Thread { private long allowedtime; private OutGate outgate; private ParkingData pdata; public OutHandler( long allowedtimeafterpayment, OutGate out, ParkingData p) { allowedtime = allowedtimeafterpayment; pdata = p; outgate = out; // Task part h) public void run() { // WRITE YOUR METHOD HERE // end of class OutHandler Trådklassen Reporter (run-metoden måste implementeras) public class Reporter extends Thread { private ParkingData pdata; public Reporter( ParkingData p) { pdata = p; // Task part i) public void run() { // WRITE YOUR METHOD HERE // end of class Reporter Slut på koden!

10 10(10) B Kort, specifik Java-referens med eventuellt lämpliga metoder Tidshantering, trådhantering, väntelägen, etc klass System: public static long System.currentTimeMillis(): aktuell systemtid i millisekunder klass Thread: public static void sleep( long t): försätta en tråd i viloläge under t ms public static void yield(): dra tråden tillbaka och sätt i kön för ny schemaläggning public void join(): vänta att tråden dör public void start(): starta upp tråden public void run(): trådens arbete klass Object: public final void wait(): försätta en tråd i vänteläge public final void wait( long t): försätta en tråd i vänteläge under max t ms. Kan väckas i förtid! public final void notify(): meddela nästa tråden i vänte-kön att ett tillstånd har ändrats public final void notifyall(): meddela alla trådar i vänteläge att ett tillstånd har ändrats