Tentamen EDA698 Realtidssystem (Helsingborg)

Transkript

1 LUNDS TEKNISKA HÖGSKOLA 1(7) Institutionen för datavetenskap Tentamen EDA698 Realtidssystem (Helsingborg) LUNDS TEKNISKA HÖGSKOLA 1(6) Institutionen för datavetenskap 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 (18 poäng), och programmering & design, frågor , och 7 (12 poäng). För godkänd (betyg 3) krävs sammanlagt ca hälften av alla 30 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 You are allowed till båda to use uppgifterna the Java quicki programmering reference and a calculator. & design (preliminärt). 1. Jämnlöpande exekvering, delade resurser och synkronisering a) Vad är en Semafor (i kontext av jämnlöpande exekvering / programmering)? Svara med ca en mening. Beskriv sen (ca en mening var) två olika typer av semaforer och förklara, vad de kan användas till! a set of threads. b) För ett system med (minst) två computer/os jämnlöpande requirements aktiviteter shouldvill be fulfilled, programmeraren and why is that använda needed? sig av en Monitor för ömsesidig uteslutning a) Processing och informationsutbyte pre-emption (pre-emptive mellan scheduling aktiviteterna of CPU time). (trådarna). På vilka sätt kan en sådan implementeras i Java? Beskriv två möjligheter! c) Ge ett exempel för ett system där det är lämpligt att använda Mailbox för kommunikation mellan olika trådar! Motivera ditt d) Priority svar med inheritance. ca en mening! d) Vad är de tre olika tillstånd som en tråd (aktivitet) i ett flertrådigt system (med enbart en CPU) kan ha? Vilka övergångar finns mellan tillstånden och vem ansvarar för att en tråd ändrar sitt tillstånd? Förklara gärna med hjälp av ett diagram och korta beskrivningar! 2. Dödlägesanalys Lisa fick en fin men enkel modelljärnväg med ett tågset i födelsedagspresent i fjol (se bilden). Nu uppdaterade mormor det hela med några tågset som påskpresent, så att Lisa kan leka rusningstrafik på rälsen , Exam Concurrent and Real-Time Programming Also dictionaries for English (and the native language for each student) is allowed. To pass the exam, grade 3, you have to solve most of the first 5 problems (which are more of a theoretical type), and you have to develop an acceptable solution to problem 6 (programming). At least a partial solution to problem 7 is required for grade To handle concurrent inputs and real-time computing of the resulting outputs, you have constructed Your real-time threads should run on an embedded computer that also runs other threads without real-time requirements (lower priority). Which of the following embedded b) Resource pre-emption. c) Strict priorities. 2. Little Lisa wishes to get model trains and tracks from Santa this Christmas, and in particular the new computerized model with configurable trains and mutual exclusion for tracks looks like a great option (at least here parents think so, but actually Lisa wants to crash trains into each other but that is another story). The starter-kit tracks look like the(1p following, + 1p + with 1p + each 3p) mutually exclusive section (shared resource) marked A to F. For a train to go into a new section, it must first (while holding the present one) wait for it to be free. Trains only go forward. Hela systemet är ett enkelspårigt ringsystem med sex rälsavsnitt A till F, där enbart ett tåg kan vara på varje avsnitt vid en given tidpunkt, dvs varje avsnitt fungerar som en delad resurs med ömsesidig uteslutning. Det som skiljer hennes system lite från den enkla Lego-versionen är signaleringssystemet som ingår och möjligheten att ge tågen individuella körsträckor, så att det är de som styr växlarna. 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. Lisa testar lite olika versioner av trafikstyrning och får i vissa fall problem: R A B C D a) Assume that trains go in the same direction (e.g. all clock-wise), and that each train is configured to always take either the left or the right track at the switches. (That is, each train is configured to always go on track C or D, and that is communicated with the switch control. The result would be the same if the selection could vary, but we simplify to fit our methods better.) Explain by referring to a resource allocation graph that more than four trains on the track will lead to a deadlock. b) Assume there are only two trains that go in opposite directions, one configured to always take the upper C branch and one that always takes the lower D branch. Update your resource allocation graph, and tell how many situations there are that result in deadlock with only these two trains. a) Hon börjar med att alla tåg ska köra åt samma håll (medsols). Vissa tåg ska alltid ta omvägen via C, alla andra tar alltid vägen via avsnitt D. Hon vill gärna ha massor med tåg på rälsen samtidigt, men vid fem stycken tar det stopp inget tåg rör sig. Varför får det inte vara fler än fyra? Förklara med hjälp av en resursallokeringsgraf där ett tåg motsvarar en tråd och ett rälsavsnitt en delad resurs! E F L (4p)

2 2(7) b) Nu vill Lisa testa något lite mera avancerat. Eftersom hon har stickspåret via C borde det väl gå att köra åtminstone två tåg åt olika håll, det ena tar alltid vägen via C, det andra via D. Hon upptäcker dock att det inte alltid går! I hur många situationer kan tågen hamna framför varandra så att de inte kan köra vidare? Använd en uppdaterad resursallokeringsgraf för att hitta situationerna! c) Kan du hjälpa Lisa att få systemet att fungera med de två tågen som kör åt motsatta håll? Tips: Det går att plocka bort signaler så att man kan lägga ihop flera rälsavsnitt till ett nytt, som vi kan kalla X. Använd gärna den nu väldigt enkla resursallokeringsgrafen för att visa att Lisa kan köra två tåg åt motsatta håll utan krock och utan dödläge! (2p + 1p + 1p) 3. Dödläge - Svält - Levande död Jämför systemtillstånden Dödläge (deadlock), Svält (Starvation) och Levande död (livelock) med varandra! Hur kan respektive situationer uppstå, vad är skillnader och / eller likheter? 4. Realtidskrav (2p) a) För att ett (flertrådigt) system ska kunna kallas för realtidssystem måste vissa krav uppfyllas. Vilka? Förklara med någon mening! b) Varför får prioritetsinvertering ej förekomma i ett system som ska uppfylla kraven? 5. Schemaläggning (1p + 1p) 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 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 a1(); 30ms A M3 a3(); 60ms b1(); 50ms b2(); 30ms B M2 Trådarnas perioder och exekveringstider: T C A B C c3(); 150ms C c2(); 20ms

3 3(7) a) Beräkna blockeringstiderna B i! b) Analysera systemet med lämplig metod! Är det schemaläggningsbart? c) Ifall det visar sig att något tilltänkt system inte är schemaläggningsbart direkt, kan man prova vissa förändringar. Ge ett exempel för en sådan förändring utifrån det givna systemet! 6. Programmering Trafikljusstyrning (1p + 2p + 1p) Stadens trafiknämnd har gett dig uppdraget att bygga ett nytt styrningssystem till korsningen på bilden bredvid. Korsningen är en vanlig sådan med två likvärdiga gator och övergångar för fotgängare och cyklister, också dem försedda med trafikljus. Fotgängarljusen slås av i standardläget (se nedan), då alla billjus ska vara röda, så att fotgängare kan korsa vägarna på egen risk. I annat läge blir dem synkroniserade med respektive billjus. Detta tar hårdvarustyrningen hand om, du behöver alltså enbart bygga styrningssystemet för billjusen! Korsningen (vägarna) är utrustade med sensorer för bilar, en bit ifrån respektive stopplinje, samt vid stopplinjen. Vi tittar i princip bara på två färdriktningar, dvs blir det grönt från norr till söder blir det också grönt för motsatta hållet. Du måste alltså hålla reda på två trafikljusgrupper (0 för trafik som går i öst väst, eller motsatt håll, 1 för trafik nord syd, och motsatt håll) och två gånger två sensorgrupper: Gatusensor 0, för inkommande trafik väst - öst (och motsatt) Stopplinjesensor 0, för trafiken väst - öst (och motsatt) Gatusensor 1, för inkommande trafiken nord - syd (och motsatt) Stopplinjesensor 1, för trafiken nord - syd (och motsatt) Korsningen är inte så starkt trafikerad, förutom under rusningstrafiken. Kunden, dvs trafiknämnden, har därför en del synpunkter för hur ljusen ska regleras, så att det blir optimalt för trafikflödet och säkert under dagens alla timmar. Följande specifikation ska uppfyllas: Samtliga billjus ska vara röda som standard, så länge det inte (längre) finns någon trafik. Ett ljus får bara ändras till grönt om det andra ljuset (dvs, alla ljus i den andra, korsande, gruppen) är rött. Om ett ljus har varit grönt, sen gult och slår slutligen om tillbaka till rött, måste det läggas in ytterligare en tidsmarginal så att bilar (och fotgängare) hinner bort från korsningen, INNAN ljusen i korsande riktning får slå om till grönt. Ett ljus måste vara grönt under en viss tidsperiod så att trafiken hinner ut på korsningen. Sensorerna vid stopplinjerna reagerar när de bedömer ha en statisk last (= stående bil) på sig. Det finns tidsperioder angivna som bilar maximalt ska behöva vänta. Sensorerna som finns en bit före stopplinjen reagerar på varje bil som passerar dem, alltså också, när ljuset redan är grönt eller gult. Om fler bilar ska passera korsningen åt samma håll, ska ett redan grönt ljus förbli grönt under en viss tidsperiod räknat från den tidpunkten då det hela upptäcks (eller ett gult ljus ska gå tillbaka till grönt) tills alla bilar har passerat, om det inte är bilar som vill komma över korsningen på det andra stråket som har väntad under den maximala väntetiden. Minimitiden för grönt ljus får dock ej underskridas! Följande tidsperioder ska gälla:

4 4(7) minimum tidsperiod för grönt ljus: 20s = 20000ms extra tidsperiod för grönt ljus: 10s = 10000ms önskad period för gult ljus vid övergång från grönt till rött: 5s = 5000ms säkerhetsmarginal efter ändring till rött: 5s = 5000ms maximal väntetid: 1min (inkl gult ljus och säkerhetsmarginal) Uppgift: En monitor (CrossRoadMonitor) ska användas för kommunikation mellan hårdvara (trafikljus och sensorer, gränssnittet som du behöver är beskrivet i klassen HW) och trådar (trafikljusdrivare, TrafficLightDriver). Sensorhanteringen kan anses som en black-box, den behöver du inte bekymra dig om. 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) Ange en lämplig tidsperiod för den maximala tiden en bil ska få vänta vid rött ljus innan bytet från grönt till rött måste påbörjas på den andra vägen (dvs, ingen extra tid med grönt ljus får läggas till), så att bilen har en sammanlagd väntetid på maximalt en minut. b) Skriv koden för monitor-metoden carapproaching, som anropas av en (befintlig, ej närmare beskriven) sensorutvärderings-tråd när en bil närmar sig. Tråden ska skicka med vägnumret, så att respektive gatusensor-räknare (caronroad[]) kan uppdateras. c) Skriv koden för monitor-metoden carwaiting, som anropas av en (befintlig, ej närmare beskriven) sensorutvärderings-tråd när en bil har bedömts blivit stående vid stopplinjen. Tråden ska skicka med vägnumret, så att respektive stopplinje-tidsräknare (waitingtimer[]) kan uppdateras. Ifall det redan står en bil på samma väg vid motsatta sidan korsningen, dvs respektive tidsräknaren inte är lika med noll, ska den dock inte ändras. d) Skriv koden för monitor-metoden changelight, så att den kan anropas från trafikljusdrivartrådar med uppgifter om vilken väg det gäller. Metoden ska se till att ovannämnda kraven uppfylls, dvs så länge det inte är någon bil registrerad, ska ljuset vara rött, och om det ska ändras måste tråden eventuellt vänta på att ljuset för den korsande vägen blir rött igen först. Sen måste de olika krav på tidsperioder (minimi-tider för grönt och gult, säkerhetsmarginal, maximal väntetid) hanteras. Du kan använda hårdvarugränssnittet HW för att skicka anvisningar till trafikljusen, men din metod borde hålla reda på tillstånden av trafikljusen med hjälp av motsvarande attribut själva. Hårdvarugränssnittet hanterar rött-gult ljus vid övergångar mellan rött och grönt ljus själv, för säkerhetens skull ska dock i monitorn den korta perioden då ljuset visar rött-gult innan det blir grönt redan räknas som grönt (eller iaf icke-rött ). Övergångar från grönt till gult och gult till rött måste hanteras av dig, eftersom det ska vara möjligt att hoppa tillbaka från gult till grönt, om det kommer en till bil och ingen annan väntar (se ovan). Hårdvarugränssnittet reagerar omedelbart, vilket kan utnyttjas för att lägga in säkerhetsmarginalen efter en ändring till rött ljus innan korsningen friges. e) Skriv koden för en trafikljusdrivar-tråd, dvs run-metoden i klassen TrafficLightDriver. (1p + 1p + 1p + 6p + 1p) 7. Design Trafikljusstyrning med fotgängar-knappar Trafikljusstyrningen verkar fungera för biltrafiken, uppdragsgivarna är nöjda. Nu har de kommit på att de vill ha en ännu säkrare och smidigare lösning för fotgängare och cyklister. Korsningens trafikljus blir alltså ändrade till att det finns knappar att trycka på, för att signalera att ljuset ska gå över till grönt. Bil- och fotgängarljusen är nu alltså inte längre sammankopplade, men såklart gäller det fortfarande, att ljusen åt ena hållet (längs en väg) är kopplade med dem i motsatt riktning, och att ett ljus (eller en ljusgrupp) inte får slås över till grönt, om inte ALLA ljus för korsande trafik är röda (inkl någon säkerhetsmarginal!). Din uppgift är nu att lägga till de delar av systemet som behövs för att hantera knapptryck och

5 5(7) extra ljusstyrning (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? Vilka ändringar behövs i befintliga komponenter? Vilka nya villkor måste man hålla reda på? Borde trafiknämnden ange nya specifikationer gällande tidsperioder och andra krav om hur korsningen ska bete sig? (2p) Slut på uppgifterna (Appendix A och B finns på resterande sidor). Lycka till!

6 6(7) A Koden till uppgift 6 Hårdvarugränssnittet som är tillgängligt via klassen HW public class HW { public static final int RED = 0; public static final int YELLOW = 1; public static final int GREEN = 2; public static void init( int colour) { // sets all lights to colour } public static void switchlight( int roadid, int tocolour) { // switch lights on road roadid from current colour to tocolour // switch from HW.RED to HW.GREEN takes care of an extra short period // with both red and yellow light automatically } //... } // end of class HW Monitor-klassen CrossRoadMonitor public class CrossRoadMonitor { private int[] trafficlight; private int[] caronroad; private long[] waitingtimer; // current colour of the light // for cars approaching // for standing car at the stop-line private long mingreentime; private long extragreentime; private long yellowtime; private long safetytime; private long maxwaitingtime; // Change if necessary public CrossingMonitor() { HW.init( HW.RED); // set all lights to red to start with trafficlight = new int[2]; caronroad = new int[2]; waitingtimer = new long[2]; mingreentime = 20000; extragreentime = 10000; yellowtime = 5000; safetytime = 5000; // Task part a) // SPECIFY THE MAXIMUM WAITING TIME, SO THAT A CAR HAS AN // OVERALL MAXIMUM WAITING PERIOD OF 60s maxwaitingtime = // your value! ; } // end of constructor // Task part b), c), and d) // WRITE YOUR METHODS HERE // task part b) // method: carapproaching( int roadid)

7 7(7) // add suitable tags, return value, and parameters! (if needed!) // task part c) // method: carwaiting( int roadid) // add suitable tags, return value, and parameters! (if needed!) // task part d) // method: changelight( int roadid, int otherroadid) // add suitable tags, return value, and parameters! (if needed!) } // end of class CrossingMonitor Trafikljus-drivaren TrafficLightDriver public class TrafficLightDriver extends Thread { private CrossingMonitor mon; private int myroadid; private int otherroadid; public TrafficLightDriver( CrossingMonitor m, int id, int crossid) { this.mon = m; myroadid = id; otherroadid = crossid; } // Task part e) public void run() { // WRITE YOUR METHOD HERE } } // end of class TrafficLightDriver B Kort 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