Eksamen i TTK4145 Sanntidsprogrammering 12. august

Transkript

1 NTNU Norges teknisk-vitenskapelige universitet Institutt for teknisk kybernetikk Fakultet for informasjonsteknologi, matematikk og elektroteknikk Bokmål Eksamen i TTK4145 Sanntidsprogrammering 12. august Sensuren vil bli avsluttet i henhold til gjeldende regelverk. Generelt: Vær konsis og klar. Skriv kort. Sett opp momenter og argumenter punktvis, bruk figurer der det egner seg. Du kan få trekk for «vås». Hjelpemidler: Tillatte hjelpemidler: D - Ingen trykte eller håndskrevne hjelpemidler tillatt. Bestemt, enkel kalkulator tillatt. Faglig kontakt under eksamen: Sverre Hendseth Telefon /5

2 Oppgave 1: Semaforer & Monitorer Sverre har et programsystem som består av flere moduler, og som har flere tråder, men ingen synkronisering av trådene omkring delte variable ("Det har jo gått bra så langt" var innstillingen når systemet ble skrevet :-). En skjelden gang kræsjer imidlertid systemet på en måte som ikke er rekonstruerbar, og Sverre har (etter et par uker med fruktløs feilleting) fått mistanke om at det er trådene som snubler i bena på hverandre på en eller annen måte. Han bestemmer seg derfor for å innføre en binær semafor for hver modul, og la alle funksjoner/metoder i modulen reservere denne så lenge de kjører. Oppgave 1 a) Hva kan konsekvensene av/ulempene ved denne strategien være? Oppgave 1 b) Monitorer er en noe mer komplisert mekanisme enn semaforer, men også mer potent. Hva tjener Sverre på å beskytte modulene med monitorer istedet for semaforer? Oppgave 1 c) Hvordan ville du løst Sverres problem; ser du bedre strategier for å fjerne problemene? I et annet programsystem forekommer følgende problemstilling; Tre tråder kan startes samtidig, men vi ønsker å styre initialiseringen (de første N kodelinjene om du vil) av trådene slik at tråd 1 får startet opp før tråd 2 som igjen skal fullføre oppstarten sin før tråd 3 kan starte. Oppgave 1 d) Vis hvordan du ville løst dette (programkode/pseudokode er ok). Oppgave 2: Delt variabel synkronisering I denne oppgaven ser vi på hvordan de forskjellige mekanismene er implementert, dvs. vi inntar perspektivet til de som lager sanntids operativsystemet. Anta en enkel mikroprosessor og en scheduler som ikke kan annet enn å holde rede på og switche imellom de kjørende trådene. De fleste mekanismene for delt variabel synkronisering er ekvivalente på den måten at de kan implementeres vha. hverandre. En eller flere grunnleggende mekanismer må alikevel implementeres "først" direkte, og uavhengig av de andre. La oss anta at vi velger en standard, binær semafor her som den grunnleggende mekanismen. Oppgave 2 a) Schedulerens funksjonalitet må utvides: Hva slags utvidelser må til i scheduleren for å håndtere slike semaforer? Oppgave 2 b) Hvilke prinsipper eller egenskaper i mikroprosessoren/hardwaren kan du bygge på for å oppnå den grunnleggende synkroniseringen. Oppgave 2 c) Vis hvordan semafor-mekanismen (wait, signal) kan implementeres. (programkode/pseudokode er ok). 2/5

3 Oppgave 3: Vranglåser Oppgave 3 a) Deadlock (Vranglås), Livelock (?) og Starvation (Utsulting) er problemer som kan forekomme i sanntidssystemer. Definer begrepene - gi et eksempel på hver. Oppgave 3 b) Boken setter opp fire betingelser som alle må være oppfyllt for at en vranslås skal kunne inntreffe. Hvilke var dette? I tradisjonelle sanntidssystemer vet vi ofte nøyaktig hvilke tråder som kan trenge hvilke resurser. Dette gjør at vi kan "programmere inn" vranglåsunngåelse at vi kan argumentere for eller bevise at vranglåser ikke kan opptre i systemet. Oppgave 3 c) List opp teknikker/metoder vi kan bruke for å unngå vranglåsproblemer basert på informasjonen om hvilke tråder som bruker hvilke resurser. Ta med hva ulempene er. Imidlertid er det ikke alltid mulig å forutse hvilke resurser alle tråder trenger på forhånd; La oss se for oss et system av intelligente sensorkjøretøyer som deler informasjon via en basestasjon, eller et prosessstyresystem hvor operatørene selv kan programmere inn alarm-situasjoner med tilhørende aksjoner i form av skript. I begge disse tilfellene kan basen/systemet få ikke-forutsigelige resursallokeringer. Oppgave 3 d) Hvordan kan vi unngå/løse vranglåsproblemer i slike systemer? Oppgave 4: Feilhåndtering Oppgave 4a) Vi kan programmere inn eksplisitte feilsjekker i et programvare system, list opp metoder vi kan bruke for å detektere at noe har gått galt. Oppgave 4b) Boken skiller imellom forward og backward error recovery; Hva er forskjellen? / Beskriv dem. Oppgave 4c) To blokker med kode en med og en uten exceptions: --- Code with exceptions try { // Do some work, raise exceptions on errors catch(some exceptions){ // Handle error --- Code without exceptions bool ok = true; { // Do some work, // clear ok and jump to end of block on error. if(ok!= true){ // Handle error List opp fordeler med exceptions-måten å gjøre det på fremfor den andre måten. Finnes det noen 3/5

4 ulemper? Oppgave 4d) (Backwards) error recovery kan gi opphav til en domino effekt ved flere samarbeidende/kommuniserende tråder hvor resultatet av en feil er at alle trådene må ta utgangspunkt i veldig tidlige "recovery points". Forklar denne effekten. Oppgave 4e) Hvordan kan en organisere error recovery ved flere samarbeidende tråder slik at en unngår problemer som domino effekten? Oppgave 5: Litt av hvert Oppgave 5a) OCCAM tilbyr synkron, ubufret kommunikasjon imellom tråder. Hva kan fordeler med dette som språkmekanisme være fremfor asynkron/bufret kommunikasjon. Oppgave 5b) En enkel "utilization-based schedulability test" for et FPS system av prosesser er gitt ved N C 1 i N 2 N 1 i=0 T i hvor N er antall prosesser, C i er worst-case execution time og T i er prosessens periode. Under hvilke forutsetninger holder denne? Oppgave 5c) "Resurskontroll" er mer enn gjensidig utelukkelse... Hva mer kan vi ønske oss fra et system for resurskontroll enn gjensidig utelukkelse? Oppgave 5d) (Ref. resurskontroll igjen;) Hva var "Blooms kriterier" ment å brukes til? Oppgave 6: Design Du jobber i et prosjekt som lager et prosesstyresystem, og du skal gjøre grovdesignet av den delen av styresystemet som tar seg av kommunikasjon imot operatørstasjonen (en annen datamaskin). På samme CPU som ditt skal kjøre går det regulatortråder som leser fra sensorer, gjør beregninger og setter ut pådrag. Disse har høyere prioritet enn operatørstarsjonkommunikasjonen og etterlater seg i normal drift en del ledig regnekraft i gjennomsnitt - mao. du kan ikke regne med å få gjort alt du vil hvert sample. I kortere perioder (som ved boot, feilsituasjoner, modusendringer...) kan du risikere ikke å få regnekraft i det hele tatt. Operatørstasjonkommunikasjonen består av sending av log så hurtig og regelmessig som det lar seg gjøre, og mottak av kommandoer som bestilling av hva som skal logges og nye settpunkter til regulatorene. Du må forholde deg til at operatørstasjonen er avskrudd i kortere eller lengre perioder, men også at nettverket er overbelastet eller nede. Opplevd kvalitet på presenterte data på operatørstasjonen er et viktig design-kriterium. Gjør antagelser mhp. funksjonalitet på regulatortrådene, operatørstasjonen og kommunikasjonsprotokollen som du finner nødvendig. "Grovdesign" innebærer her at du skal overbevise om at du er på riktig spor når det gjelder designet, dvs. at du skal ta de design-avgjørelsene som har størst konsekvenser for resten av designet og de "vanskelige" design-avgjørelsene, hvor det ikke er åpenbart om det finnes en løsning eller hva som er 4/5

5 løsningen. Vær oppmerksom på at presentasjonen i seg selv er en viktig del av svaret på denne oppgaven. Noen velmente hint: Ta eksplisitt stilling til hvilke problemstillinger som du sikter på å løse i dette grovdesignet. Ser du flere "grovdesign" type problemstillinger enn du vil/rekker å svare på, så gjør et utvalg. Kladd designet ditt først og så presenter det i besvarelsen. Ikke lever sider med "betraktninger underveis". 5/5