1 / 38

Fra harde µ-sekunder via mjuke sekunder til forte år Sann tid i industrien

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.

luigi
Télécharger la présentation

Fra harde µ-sekunder via mjuke sekunder til forte år Sann tid i industrien

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Fra harde µ-sekunder via mjuke sekunder til forte årSann tid i industrien NTNU, fag TTK 4145Real-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

  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) • http://home.no.net/oyvteig/ <= 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 • C • 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 • Brannvarsling • Brannvarsling • Motormålinger og effektberegninger • Brannvarsling • Brannvarsling Ø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 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)

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

  12. Asynkronvs. 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 • 1988-90 • PL/M-51 • Egenutvikletmailboksbasert kjøresystem • I begge prosessorene • Kooperativ scheduling • Interrupt tar detsom 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 kanalenmed 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 regelalt 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 voidP_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: • http://www.cs.kent.ac.uk/projects/ofa/jcsp/ • http://home.no.net/oyvteig/pub/pub_details.html#ProtocolDesign ØT (2004)

  28. ALT igjen 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 parallelleaktive 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 rekursjonkunne 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å 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)

  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 semantikknå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)

More Related