Objektorienterad Realtidsprogrammering 2000

1. • Realtidsrelaterade nyheter i CORBA 3• Designmönster med relationer till realtidsprogrammering• Skräpsamling och realtidsprogrammering Objektorienterad Realtidsprogrammering 2000 Föreläsning 12 Tisdag 7/6 2000

2. CORBA 3 (se http://www.omg.org/news/pr98/compnent.html) • Nyheter i CORBA 3 • Internet integration • Firewall • Interoperable Name Service • URLformat • tex, iioploc://www.omg.org/NameService

3. ... • Quality of Service Control • Asynkron meddelandesändning och Quality of Service Control • asynkron och tidsoberoende meddelandesändning • Minimal CORBA • För i huvudsak inbäddade system • Fault-Tolerant • Real-Time CORBA • standardiserar resurskontroll, trådning, protokoll, anslutning, etc • använder prioritetsmodeller för att få förutsägbart beteende för både hårda och statistiska realtidsomgivningar

4. ... • CORBACOMPONENTS PACKAGE • CORBAcomponents and CORBAscripting

5. Object Interconnections • Nytt är • asynchronous method invocation (AMI) • time-independent invocation (TII) • general messaging quality of service (QoS) semantics • Tidigare meddelandespecifikationer • Synkron tvåvägs • skicka fråga vänta på svar • Problem: blockerar tråden under väntan på svar från servern • Går att lösa med flera trådar hos klienten, vilket kan vara bökigt • Envägs • skicka fråga utan att vänta på svar • Problem: ej garanterad leverans, dom flesta ORBar implementerar detta med TCP • Fördröjd synkron • skicka fråga “kör vidare” och polla senare för svar • Problem: kräver Dynamic Invocation Interface (DII), som är lite omständlig

6. Asynchronous method invocation (AMI) • Ett tvåvägsmeddelande returnerar antingen • Poller • Pollern kan användas för att undersöka status för svaret och läsa detsamma • ReplyHandler • ReplyHandlern skickas med som parameter vid anropet och då svaret klart på servern så anropas denna callback-rutin • Fördelar • En enda tråd kan användas vid flera “överlappande” meddelanden till server

7. Time-Independent Invocation • För att kunna använda en “lagra-och-vänta”-strategi införs TII • I TII kan man definiera att ett meddelande skall skickas senare eller då, exempelvis, en förbindelse etablerats

8. Messaging Quality of Service (QoS) • Med denna nya service har vi som programmerare möjlighet att kontrollera bla • Synkroniseringspolicies • Meddelandeprioriteter • Timeout för meddelandesändningar • Routing av meddelanden • Rebind policies • Tex om enkelvägsmeddelande skall ha garanterad leverans eller ej (dvs om synkronisering med servern skall ske eller ej) • Kontrollera ordningen för köade meddelanden

9. Minimal CORBA • Det finns också ett förlag på minimal CORBA avsedd för inbäddade och realtidssystem • Detta är i dagsläget en nedskalad version av CORBA 2.2

10. Några designmönster • Nedan följer ett antal designmönster som kan vara av nytta i realtidssystem • Mallarna är medvetet kort-korta för att bara ge en snabb översikt av några mönster • Självklart finns det många andra mönster som kan vara intressanta dessa är bara några korta exempel

11. Transaction pattern • Syfte • Kontrollera kommunikationen mellan objekt med möjlighet att ange tillförlitlighet • Problem • I ett realtidssystem kan olika meddelanden vara olika kritiska och ha olika tillförlitlighetskrav. Vidare kan olika undeliggande transportmedia vara olika tillförlitliga • Lösning • Skapa speciella objekt som skickar över respektive tar emot meddelanden • Dessa objekt skall kommunicera med varandra för att se om meddelandet kommit fram och behandlats, annars kan sändaren skicka om det hela Douglass2 figur 6-3

12. Smart Pointer • Syfte • Undvika problem med dumma pekare i tex C++ • Problem • Problemet med pekare är välkänt i C/C++ • dom kan användas innan dom är initierade eller efter minnet dom pekare på frigjorts • vi kan också ha minnesläckor, felaktiga adresser kan användas, osv • Lösning • Skapa en klass med konstruktor och destruktor som indirekt pekar ut minnesadressen Douglass2 figur 6-4

13. Rendevouz • Syfte • Erbjuda en flexibel mekanism för lättviktig interprocesskommunikation • Problem • Det är inte helt enkelt att synkronisera flera parallella processer • Lösning • Skapa ett speciellt Rendezvous-objekt som olika processer använder för att synkronisera Douglass2 figur 6-8 och 6-9

14. Några andra mönster i ännu kortare form • Latch (Douglass 12.3.1 och Lea bla s 229) • kom ihåg att ett visst tillstånd har inträffat • i Lea används en Latch som bara kan ändras en gång • Watchdog (Douglass 12.3.4) • gör en kontinuerlig check om process lever (eller omvänt meddela kontinuereligt att process lever) • Om meddelande uteblir: starta om systemet

15. Skräpsamling i realtidssystem • I Jones och Lins bok Garbage Collection beskrivs flera algoritmer som passar för realtidssystem [se utdelat material] • Dock gör man troligt (avsnitt 8.9) att skräpsamlare för hårda realtidssystem måste ha hårdvarustöd • i enbart mjukvara kommer man ner på i värsta fall ca 50 mikrosekunder för varje atomisk operation men med hårvarustöd kan man nå värsta-fall på 1 mikrosekund (boken skriven 1996) • ett förslag är att använda en speciell hårdvaru-minnesmodul • bla för att hålla ner kostnaderna