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 http://home.no.net/oyvteig/ Autronica Fire and Security (AFS) - A Kidde company Oppdatert 15.nov.06

”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)

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

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)

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) .!

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) .!

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) .!

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)

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)

Lange år OO er fra sekstitallet I bruk nå, men lite i embedded Sanntidsmekanismer fra 60-70+ 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)

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)

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)

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)

En liten og ny boks 2003 C Egenutviklet SDL kjøresystem - asynkrone meldinger Egenutviklet CSP lag oppå: synkrone og blokkerende kanaler 1988-90 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)

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)

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

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)

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

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

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

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)

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)

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)

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)

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)

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)

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: http://www.cs.kent.ac.uk/projects/ofa/jcsp/ http://home.no.net/oyvteig/pub/pub_details.html#ProtocolDesign ØT (2004)

ALT igjen Jeg forstår ikke bruk av eksempel Side 106 i "The Unified Modeling Language Reference Manual, Second Edition", Rumbaug, Jacobson, Booch - ISBN 0-321-24562-8 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)

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)

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)

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)

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)

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å 60-70 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)

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

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)

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)

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)

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)