NTNU, fag TTK 4145 Real-Time Programming

Presentasjon om: "NTNU, fag TTK 4145 Real-Time Programming"— Utskrift av presentasjonen:

1 Fra harde µ-sekunder via mjuke sekunder til forte år Sann tid i industrien
NTNU, fag TTK 4145 Real-Time Programming Gjesteforelesning, 2004, 2005 og 2006 Øyvind Teig Autronica Fire and Security (AFS) - A Kidde company Oppdatert 15.nov.06

2 ”Softblinking” - harde µ-sekunder
I iBook og i en ny embedded enhet fra Autronica Alle kan se at dette er en lysdiode Et avbrudd hvert 100 µ-sekund kan få den til å blinke sakte hvert 2-3 sekund Tips: pulsbreddestyring av lysdioden Hard sanntid - men ”sanntidsprogrammering”? Sto ikke i spek’en Sjefene hardblunka litt... men det tok jo bare en par timers arbeid... etter at jeg likevel måtte polle noe hvert 100 µ-sekund! ØT (2004)

3 Fagbakgrunn NTH, 1975 HW design SW design Embedded systemer hele tida
Publisert en del (se hjemmesida mi) <= 38 Du finner referanser til alt jeg har nevnt i denne forelesningen i artikler der ØT (2004)

4 Firmabakgrunn ”Autronica, Lade” Samme sted, fem logoer
Autronica - børs - Whessoe - Navia Splitt og bli rik: Kongsberg + AFS = To selvstendige firma Jeg har jobbet i ”alle” disse firmaene Ansatt i Autronica Fire and Security (AFS) AFS ble eid av Kidde (2004) som ble kjøpt av United Technologies UTC (2005) NB! Punktene i denne forelesningen står for egen regning! ØT (2004)

5 Pappesken (1) HW/SW for 30 år assembler PL/M Modula-2 MPP-Pascal occam
occam, et dødt språk, ja vel men (påstand): i forhold til concurrency dilter UML bare etter C++? EC++? ETC++? Java? ØT (2004) .!

6 Pappesken (2) Som sagt, nesten 30 år Ikke en kjedelig dag! ?
Meningsfylt! Sanntidsprogrammering er gøy! Og det kommer bare til å bli mer og mer av det! Papirtape (NTH, 1975) Sann tid går ganske fort! ØT (2004) .!

7 Pappesken (3) 1978: Ikke noe kjøresystem, ren assembler
1979: MPP Pascal med prosessbegrep og kjøresystem 1980: PL/M med NTH-utviklet kjøresystem 1982: Assembler med hjemmesnekret kjøresystem 1988: PL/M med hjemmesnekret kjøresystem 1988: Modula-2 med kjøpt kjøresystem 1990: occam med prosessbegrep og kjøresystem 1995: C med VxWorks 2003: C med hjemmesnekret SDL (&CSP) kjøresystem Dieselaggregat start/stopp nødstrøm Protokollkonvertering, radarbasert nivåmåling og brannv. Maskinromsovervåking Brannvarsling Motormålinger og effektberegninger ØT (2004) .!

8 ALT ALT i occam alt i Limbo select i Ada accept if/fi i Promela
alt i UML 2.0 (semantikken?) select i Unix er ikke det samme! (ingen guarder) ØT (2004)

9 ALT != if Om flere guarder er sanne
dvs. man er klar til å motta på flere kanaler skal det ikke velges som ved if-then-else Man skal velge ikke-deterministisk ikke-deterministisk = tilfeldig Finnes som sagt i UML 2.0 (også i UML sine state maskiner, helt rimelig - for en state maskin kan betraktes som en prosess) ØT (2004)

10 Lange år OO er fra sekstitallet I bruk nå, men lite i embedded
Sanntidsmekanismer fra tallet. Semafor etc. i bruk siden da CSP etc. fra 70-tallet. Lite i bruk (ennå?) UML 2.0 snart ute – stort og uten aksjonsspråk Java “synchronized” – det første allment brukte språket som overhodet har noe concurrency-tankegang innebygd ..men som er ”livsfarlig” å bruke! ..og som det går an å bygge CSP oppå! Hallo, dette går da ikke fort! ØT (2004)

11 Meldingskanaler Synkron, blokkerende (occam eller CSP-skall) Enveis
Synkron, blokkerende (Ada) Toveis Asynkron ikke-blokkerende (SDL) Asynkron ikke-blokkerende (socket) Alle typene Kan brukes.. Bør brukes! ØT (2004)

12 Asynkron vs. synkron komm. (1)
Asynkron – du kan ikke forhindre at du kan miste data (Buffer overflyt) Du må programmere det å ikke miste data når du trenger det (Vent på kvitteringsmelding) Synkron – du mister aldri data (Blokkering) Du må programmere det å tillate å miste data når du trenger det (Aksepter alltid og kast (gjerne i egen “overflowbuffer”)) ØT (2004)

13 Asynkron vs. synkron komm. (2)
Asynkron komm. og buffer overflyt på dette nivået får hele systemet til å kræsje! Og du kan ikke lett designe bort dette problemet! Synkron komm. og vranglås får også hele systemet til å kræsje! Men du kan designe bort lukkede sirkler av avhengighet! ØT (2004)

14 En liten og ny boks 2003 C Egenutviklet SDL kjøresystem - asynkrone meldinger Egenutviklet CSP lag oppå: synkrone og blokkerende kanaler PL/M-51 Egenutviklet mailboksbasert kjøresystem I begge prosessorene Kooperativ scheduling Interrupt tar det som trengs av preemption Atmel ATMega128 2003 Softblink power on Maskebrent 8052 fra 1988 ØT (2004)

15 Roller (1): to sjefer Synkrone kanaler og to initiativtakere?
Bruk f.eks. to synkrone kanaler og en asynkron signalkanal Eller bygg om den ene asynkrone kanalen med to synkrone og en bufferprosess (Buffer) Da vil man kunne sende en ”asynkron” melding ØT (2004)

16 Roller (2): familiebilde
ALT MASTER SLAVE Rene meldings- leverandører Dataflytreninger: ØT (2004)

17 Roller (3): opp og ned og ned og opp
Valg av rolle spiller egentlig ingen rolle Slik designet jeg det, men jeg kunne f.eks. ha latt ”retningen” snu i 5:P_BS100_Sim Hovedsaken er å få data dit du skal Uten polling deadlock ØT (2004)

18 Roller (4): bortover produsent  forbruker ØT (2004)

19 Overflytbuffer P_A sender til P_B og P_B til P_A
Kontroll på overflyt uten meldingskøoverflyt ØT (2004)

20 Sekvensdiagram (SD) Fine saker! ØT (2004)

21 Fra semaforer til en stor mainprosess
Semaforer er relativt vanskelig å bruke rett Derfor, inn med meldingskøer! (bra) Da føles de asynkrone best Og man lager tråder som sender til en diger mainprosess Huff og huff! Ikke ha trådvegring! Lag en prosess per (stor) funksjon! Ikke ha synkronkanalvegring! De er ikke så stive! Den der mainen blir som regel alt for komplisert og det blir alt for mange hendelser å håndtere, og tilstander som går i beina på hverandre, og meldinger som snakker i munnen på hverandre, og det er ikke like lett å oppdage slikt bestandig, inni masse kode, for du har jo ikke egentlig designet dette, det bare gror og gror..(?) ØT (2004)

22 Men lysdiodeblinking, da?
Inne i denne main prosessen er det vel kurant å håndtere en timer sammen med det andre for å kunne blinke bare en lysdiode av og på? Jada! Men – om flere ønsker å styre denne blinkingen.. og ha mer systematisk kontroll på den? Bort med main prosessen! Inn med en egen prosess som pakker inn og beskytter denne delte resursen Eller flere lysdioder som skal blinke i takt Eller enda litt flere pulserende utganger Da får du en ”utgangsdriver”, et mye mer skalerbart konsept ØT (2004)

23 Kanallag over asynkront meldingssystem
case ST_STATE_IN_ALT_030_032_104_105_A: { { bool_a alt_taken; g_ALT_BS100_Sim = CHAN_ALT_ENABLED_ON_A; alt_taken = FALSE; ALT_CHAN_IN_ASYNC_SIGNAL_F (ContextPtr->Guard_032, g_chan_032, S_EVENT_ALT_032_A, &alt_taken); ALT_CHAN_IN_ASYNC_SIGNAL_F (ContextPtr->Guard_104, g_chan_104, S_EVENT_ALT_104_A, &alt_taken); ALT_CHAN_IN_F (ContextPtr->Guard_030, g_chan_030, ContextPtr->ALCP_030i, S_EVENT_ALT_030_A, &alt_taken); ALT_CHAN_IN_F (ContextPtr->Guard_105, g_chan_105, ContextPtr->ASSP_Inner_105i, S_EVENT_ALT_105_A, &alt_taken); ALT_TIMER_IN_F (ContextPtr->Guard_Timer, ContextPtr->Timeout_mS, TU_MS_A, S_EVENT_TIMEOUT_A, &g_ALT_BS100_Sim, &alt_taken); ContextPtr->State_Previous = ST_STATE_IN_ALT_030_032_104_105_A; ContextPtr->State = ST_STATE_IN_ALT_030_032_104_105_END_A; DEBUG_PRINT_BS100_SIM_1_A } break; } Makroer i C og CSP-lag oppå SDL Dette er P_BS100_Sim ”hovedventested” Kok fra SPoC (occam til C oversetteren) ØT (2004)

24 Process i dette systemet
void P_BS100_Sim (void) { ContextPtr_a ContextPtr = (ContextPtr_a)g_ThisExtPtr; switch (ContextPtr->State) { ST_INITIALIZING_A (Initialize) ST_STATE_IN_ALT_030_032_104_105_A > ST_STATE_IN_ALT_030_032_104_105_END_A ST_STATE_OUT_031_A ST_STATE_OUT_033_A ST_STATE_OUT_110_A ST_STATE_OUT_999_A ST_STATE_OUT_999_HW_PIN_A ST_STATE_OUT_999_PRINT_A ST_STATE_OUT_END_A /// ST_STATE_STOPPED_A, (crash) default, (crash) } Common action: get more to do from workpool } Kommunikasjons-fase-tilstander Obs foldende programeditor ... Inneholder C-kode ØT (2004)

25 Kommunikasjons-fase-tilstander
Forsøk på å beskrive dem i noen SDL-liknende kruseduller Legg merke til work pool et tabelldrevet oppslagsverk Prosessen skal jo ikke bare event-drives utenfra men også ta egne initiativ ØT (2004)

26 Mimre, mimre Komm Komm Display kort 20 bit a/d Lysføler Loader kort
PIC 1995 occam (her) C (UK) Inni 20kg EX boks med vindu Literate programming Word -> foldende Installert: ingen! - ikke alt man lager blir noe av! transputer 4x20Mbit/S linker, rtx scheduler og 1S prosess svitsjetid mer RAM ØT (2004)

27 CSP for Java = JCSP import jcsp.awt.*; import jcsp.lang.*;
public class Protocol class MyProducer implements CSProcess private final ChannelOutput out; private Protocol prot; prot.transit (out); class MyConsumer implements CSProcess prot = (Protocol) in.read(); label = (Label) prot.read_Label(); prot.take_Element(); class Test implements CSProcess{ public Test(){ final One2OneChannel c = new One2OneChannel (); MyProducer prod = new MyProducer(c); MyConsumer cons = new MyConsumer(c); new Parallel (new CSProcess[]{prod,cons}).run(); } public void run(){} Denne koden henger ikke sammen, jeg har bare samlet noen godbitlinjer Men om du synes den ser spennende ut, se: ØT (2004)

28 ALT igjen Jeg forstår ikke bruk av eksempel
Side 106 i "The Unified Modeling Language Reference Manual, Second Edition", Rumbaug, Jacobson, Booch - ISBN Jeg forstår ikke bruk av eksempel Hvorfor viser de synkron retur fra en og samme klasse? Hvorfor ikke svar fra to parallelle aktive objekt? ”alt” skal være ”non-deterministic” I eksempelet er det bare ”if-then-else”? ØT (2004)

29 Sanntidspatologi Deadlock, livelock, starvation
Operativsystem meldingsbuffer overflyt Heap overflyt Stack overflyt En stack per prosess om vi har preemptive scheduling En stor stack om kooperativ scheduling Uten rekursjon kunne stacksize vært beregnet av linkeren! State machine (deadlock, livelock, utsulting, stopp) Array index overflow ØT (2004)

30 PROC som styrer over sin egen kropp
Repetisjon: Synkrone kanaler og guards medfører at en prosess som benytter slike kan styre andres bruk av seg og kan velge å ikke ”bli brukt” Ikke aksepter klasser og mekanismer hvor slikt ikke tilbys! ØT (2004)

31 PROC som dør i låste favntak
Repetisjon: for sterk binding (synkrone kanaler feil brukt) kan medføre at prosesser som benytter slike lettere enn ellers kan komme til å vente på hverandre i låste favntak = vranglås Fienden er lukkede sirkler av avhengighet! ØT (2004)

32 Ikke alle favntak bør begynne!
Repetisjon To kan holde på i et lukket favntak Det kan medføre eventuelt andre i rommet (ellers kalles det livelock) etter hvert må vente på de som er opptatt Til slutt kan alle stå som saltstøtter og vente på hverandre Igjen: fjern lukkede sirkler av avhengighet ØT (2004)

33 Litt for ”forte” år ”Ta pent imot” UML 2.0
Følg med i sammensmeltingen mellom ”object”-begrepet og ”process” / ”thread” / ”task” Obs på begrep som ”active object” (spennende) Mange av basiskonseptene for sanntidsprogrammering ble funnet opp på tallet semafor, guarded commands monitor (≈ Java Synchronized), SDL, CSP Ikke bare spis grandiosaen blant dem Den er ikke så grand som du tror Send meg gjerne en mail Diplom, prosjektoppgaver? ØT (2004)

34 App. (endix): Punkt som ble diskutert på de to presentasjonene som er gjort (NTNU og på AFS) derfor 4 sider til …

35 App. (1): Deadlock i asynkron komm.
Asynkron kommunikasjon kan også gå i vranglås! Enten på applikasjonsnivå, eller på kjøresystemnivå: Buffere designes ofte med blokkerende semantikk når de går fulle I MPI message passing standarden kalles et ”safe” system et som har null bufring og synkron komm. ”k-safe” er et system som har k buffere og som garantert fungerer ØT (2004)

36 App. (2): Lett – ikke vanskelig
Om du benytter synkron kommunikasjon = null bufring og blokkering og guarder og pakker inn delte ressurser i prosesser og designer bort vranglås utsulting livelock – er sanntidsprogrammering lett! Og, for all del – legg in asynkronitet der det er nødvendig! All erfaring viser at du blir ferdig med slike system! og kan gå videre og lage nye! (..i større grad.. etc..) Det vil til slutt overbevise sjefen din! ØT (2004)

37 App. (3): Gjør ? når det er fullt
Du kan benytte asynkrone meldinger og sjekke om det er plass i bufferet før du sender Da unngår du meldingsoverflyt .. .. men adderer til gjengjeld kompleksitet i senderprosessen Når skal du prøve igjen? (privat schedule) Når skal du kaste? (unødvendig overflyt?) Tenn rød lampe om du ser at prosessene dine driver med (mye?) ”privat schedulering” av operativsystemmekanismer ØT (2004)

38 App. (4): Blokkér hvis fullt
Alternativt: asynkront til fullt .. .. Så, ikke overflyt, men blokkering Slettes ikke dumt, det heller! Promela: 0 buffers  Synkron og blokkerende N buffers  Asynkron så lenge det er plass Synkron og blokkerende når fullt DETTE VAR ENDELIG SISTE FOIL  ØT (2004)