Fra harde µ-sekunder via mjuke sekunder til forte år

Sann tid i industrien

NTNU, fag TTK 4145Real-Time ProgrammingGjesteforelesning, 2004, 2005 og 2006

Øyvind Teighttp://home.no.net/oyvteig/

Autronica Fire and Security (AFS)- A Kidde company

Op

pd

ate

rt 15.n

ov.0

6

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

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

Du finner referanser til alt jeg har nevnt i denne forelesningen i artikler der

<= 38

Ø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

• 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

Pappesken (3)

Ø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

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

AtmelATMega128

2003Maskebrent8052 fra

1988

Softblinkpower on

• 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

Ø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 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 meldingssystemcase 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 systemetvoidP_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

transputer 4x20Mbit/S linker, rtx scheduler og 1S prosess svitsjetid mer

RAM

Displaykort

Lysføler

Komm

Komm

20 bit a/d

Loaderkort 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

Ø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://home.no.net/oyvteig/pub/pub_details.html#ProtocolDesign

import jcsp.awt.*; import jcsp.lang.*;

public class Protocolclass 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(){}}

Ø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 0-321-24562-8

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

App. (endix):

Punkt som ble diskutert på de to presentasjonene som er gjort (NTNU og på AFS)

derfor

4 sider til …

Ø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

Ø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