Plan for dagen. Kræsj-kurs i sanntidsprogrammering. Måter å tenke på. Programmering intro. Tråder & synkronisering

Transkript

1 Kræsj-kurs i sanntidsprogrammering 1. Amanuensis Sverre Hendseth Teknisk Kybernetikk. Plan for dagen Programmering intro Tråder & Synkronisering Non-preemptive scheduling wait/signal semaforer monitorer Prosesser & Kommunikasjon Synkron/asynkron kommunikasjon CSP (OCCAM) Tilstandsmaskiner Programmering intro Måter å tenke på Å produsere kodelinjer er ikke problemet... Å legge tilrette for vedlikeholdbarhet er... --> Design! Å løse problemet med passende begreper Svarer som regel ikke til termene i programmeringsspråket. Moduler/biblioteker er et virkemiddel, men vi må ha innkapsling.? Oppdeling i funksjoner Transaksjoner Dataflyt/datalagring? Objekter Tilstandsmaskiner? Design patterns / generic objects Tråder & synkronisering Prosesser & kommunikasjon

2 Non-preemptive scheduling while(true){ utfør neste oppgave Trenger Aktiv ventekø av prosesser Prioriteter Timer grensesnitt Ventekøer for andre eventer linjer C gir en god scheduler. Fordeler Non-preemptive scheduling Lite & lett, trenger lite infrastruktur Ikke noe problem (?) med samtidig aksess av variable. Ulemper Trådene må returnere frivillig, arbeidskrevende jobber må deles (Gir kompliserte tråder tilstandsmaskiner?). Samarbeidende tråder må fortsatt synkroniseres. Krever kjerne thread1(){ i = i+1; thread2(){ i = i-1; Preemptive scheduling Wait/Signal Wait legger en tråd i ventekø på et event Signal representerer eventet, legger tråden tilbake til aktiv-køen. (I preemptive contekst:) Kan implementeres ved atomiske instruksjoner (1. assembly instruksjon) Hvordan beskytter vi en resurs?

3 Bedre: semaforer Fortsatt wait & signal kall, men semaforen representerer resursen thread1(){ wait(sem_i); i = i+1; signal(sem_i); thread2(){ wait(sem_i); i = i-1; signal(sem_i); Ulempe; Om dette virker avhenger av alle andre steder semaforen brukes... Sidesprang: Deadlock/Vranglås: Systemet kommer ikke vidre: Typisk: to tråder reserverer to resurser i omvendt rekkefølge. Livelock: Flerprosessversjonen av evig løkke. Starvation/utsulting: En prosess får tilfeldigvis ikke kjøre Monitor Def: Et sett av prosedyrer som alle er beskyttet av samme semafor. Tanken er innkapsling; En modul kan selv styre hvordan den brukes. Men: Hva skjer hvis vi har behov for å vente inne i monitoren? standard løsning at monitoren blir åpnet ved venting. Men: Hva om en monitor kaller en annen, og vi venter i den innerste? Synkronisering vha. delte variable. Standard mekanismer, trandisjonelt Real-Time pensum. Men dårlig egnet til å bygge innkapslede moduler.

4 Alternativ: Prosesser & kommunikasjon. Gratis synkronisering siden mottak må skje etter sending. (Uheldigvis:) Standardmekanismen her er asynkron, bufret kommunikasjon... Hva om bufret går fullt? Vi sparer på gamle data? Verden tar feil! Real-Time systemer er ikke implisitt kompliserte. Oppdeling av oppgaven i flere tråder er en hensiktsmessig måte å designe et program på. Det er tilnermingen det er noe feil med! Vi mister synkroniseringsmulighet v. at sender venter på mottager. Gir lett like rotete systemer (dvs. vanskelig å resonnere på) som semaforer/monitorer. Bufre bør bare brukes der du konseptuelt har bruk for bufre! Løsningen: Ubufret, synkron kommunikasjon imellom prosesser Communicating Sequential Processes CSP OCCAM Transputere JavaCSP, SPoC, CCSP Kapsler i UML Real-Time Analyseverktøy... Occam eksempel, buffer: PROC buffer(chan OF INT in,out) VAL INT buffersize IS 5: [buffersize] CHAN OF INT buffer: PAR INT v: WHILE TRUE SEQ in? v buffer[0]! v PAR i=0 FOR buffersize - 1 INT v: WHILE TRUE SEQ buffer[i]? v buffer[i+1]! v INT v: WHILE TRUE SEQ buffer[buffersize-1]? v out! v :

5 CSP: Systemdesign: Prosessen/serveren er modulbegrepet. Går igjennom en veldefinert sekvens av hendelser. Analyserbart! P1 P2 P4 Prosessen bestemmer selv hvordan den kan brukes ingen avhengigheter til annen kode --> Vi har oppnådd innkapslingen. P3 SPoC Southhampton Portable Occam Compiler Occam til C oversetter Embedder C lett! Non-preemptive scheduling i bunnen Veldig lite runtime system Skriv tråder & synkronisering i occam, gjør det som skal gjøres i C... Sanntidssystemer: Sanntidskrav hvor kom de inn? Prioriteter hvor kommer disse inn? Vi har andre krav også: Feilhåndtering Tilgjengelighet Sikkerhet... Vær oppmerksom: Dette kan ikke legges til etterpå!

6 Har ikke snakket om: Scheduling Transaksjoner Konkrete mekanismer (f.eks. POSIX) Tilstandsmaskiner Den andre måten å tenke på. Applikasjon: Komplisert oppførsel Støttes direkte bare av få spesialiserte programmeringsspråk. Haugevis av ad-hoc verktøy imidlertid. Eksempel - Kasettspiller 6 knapper (Play, Stop, Record, FF, RW, Pause) Elektronikk (Av, Play, Record) Mekanikk (Play, Stop, Open) Motorer (Play, Stop) Indikatorer (Kasett, Skrivebeskyttet, MotorGår) play(){ mekanikk_play(); motor_play(); elektronikk_play(); Feil måte: Første forsøk

7 bool play; bool record; bool pause; bool ff; bool rw; Feil måte: Andre forsøk play(){ if(play == false && kasett()){ if(ff rw){ mekanikk_stop(); ff = false; rw = false; mekanikk_play(); motor_play(); if(record == false){ elektronikk_play(); play = true; Riktig måte Bestem lovlige tilstander Bestem lovlige transisjoner Knytt transisjoner til eventer (play, stop, ff etc.) Knytt aksjoner til transisjonene. Tilstandsmaskindiagram Tilstandsmaskin tabell Fratilstand TilTilstand Eventer Betingelser Aksjoner Stop Play Play Play Play Stop Stop Stop Eject Stop RecordReady Record Skrivbar RecordOn RecordReady Record Play Play Stop Open Eject Open Open Stop Kasett Rewind FastForward FastForward Stop FastForward...

8 ... og koden play(){ switch (g_state) { case State_Open: break; case State_Stop: action_play(); g_state = State_Play; break; case State_Pause: action_play(); break; case State_Rewind: action_stop(); action_play(); g_state = State_Play; break; case State_FastForward: action_stop(); action_play(); g_state = State_Play; break; case State_Play: break; case State_RecordReady: action_play(); g_state = State_Record; break; case State_Record: break; case State_RecordPause: action_play(); g_state = State_Record; break;