Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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.

Liknende presentasjoner


Presentasjon om: "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."— 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 ØT (2004)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!

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

4 Ø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!

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

6 Ø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!.!.!

7 ØT (2004)7.!.! •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 •Brannvarsling Pappesken (3)

8 ØT (2004)8 ALT •ALTi occam •alti Limbo •selecti Ada •accept if/fii Promela •alti UML 2.0 (semantikken?) •selecti Unix er ikke det samme! (ingen guarder)

9 Ø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)

10 Ø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!

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

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

13 Ø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!

14 ØT (2004)14 En liten og ny boks Atmel ATMega Maskebrent 8052 fra 1988 Softblink power on •2003 •C•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

15 Ø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

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

17 Ø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

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

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

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

21 ØT (2004)21 Fra semaforer til en stor main prosess •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 main prosess •Huff og huff! •Ikke ha trådvegring! •Lag en prosess per (stor) funksjon! •Ikke ha synkronkanalvegring! •De er ikke så stive! Den der main en 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..(?)

22 Ø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

23 Ø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)

24 Ø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

25 Ø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

26 ØT (2004)26 transputer 4x20Mbit/S linker, rtx scheduler og 1S prosess svitsjetid mer RAM Display kort Lysføler Komm 20 bit a/d 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! Mimre, mimre

27 ØT (2004)27 CSP for Java = JCSP •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://www.cs.kent.ac.uk/projects/ofa/jcsp/ •http://home.no.net/oyvteig/pub/pub_details.html#ProtocolDesignhttp://home.no.net/oyvteig/pub/pub_details.html#ProtocolDesign 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(){} }

28 ØT (2004)28 ALT igjen •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”? Side 106 i "The Unified Modeling Language Reference Manual, Second Edition", Rumbaug, Jacobson, Booch - ISBN

29 Ø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

30 Ø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!

31 Ø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!

32 Ø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

33 Ø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?

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

35 ØT (2004)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

36 Ø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!

37 Ø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

38 Ø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 


Laste ned ppt "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."

Liknende presentasjoner


Annonser fra Google