-scherzhaft- Na, kannst du dir schon denken, welche Frage gestellt wird?
Kein bisschen. Haha. Gut, man hat die Unterscheidung zwischen weichen, festen und harten Terminen.
weich: Terminverletzung tolerierbar, Ergebnis hat weniger Wert
fest: Terminverletzung tolerierbar, Ergebnis wertlos
hart: Terminverletzung intolerierbar, Ausnahmesituation wird eingeleitet, alle anderen Jobs werden angehalten und ignoriert - die Anwendung wird gefragt, was zu tun ist.
Du studierst Informatik, oder? Ich habe mich schon immer gefragt, wieso wir eigentlich Ausnahmebehandlungen brauchen. Wir berechnen doch die WCET, benchmarken und treffen alle Vorkehrungen, um Systeme nicht auszulasten, sodass es im schlimmsten Fall noch zur Ausführung aller Tasks kommen kann. Wozu also Ausnahmebehandlungen?
Ich war nicht vorbereitet für diese Frage und habe Slack-Stealing angesprochen oder dynamische Deadlines bei einer sporadischen Aufgabe, was er aber nicht hören wollte. Er sagte, dass es eine Transferfrage ist und so in den Folien nicht steht - hat mich dann langsam herangetastet und sind dann darauf gekommen, dass wir „keine Götter“ sind und unsere Messungen und Berechnungen falsch sein können - wir deshalb die Ausnahmebehandlungen trotzdem benötigen!
Stichpunkt WCET - wir haben ja verschiedene Formen kennengelernt, theoretische Schranken und messbasiert. Was braucht man, um ein Echtzeitsystem zu messen und welche Probleme und Vorteile hat das zusätzlich?
Ein Messgerät z.B. Oszilloskop oder Zeitgeber der CPU
Manuelle Analyse der Funktion/des Codes, um den schlimmsten Fall ausfindig zu machen, eventuell Parameter brute-forcen (bei kleineren Funktionen)
Problem: wie misst man richtig? Verdrängung etc. zerstören die Analyse!
Problem: WCET Analyse geht grundsätzlich immer von Cache Misses aus! Bei messbasiert hier aufpassen.
Vorteil gegenüber mikroskopischer/makroskopischer Analyse: mikroskopisch ist abhängig von Architektur, da gewisse Assemblerbefehle länger dauern als andere - makroskopisch findet den längsten Pfad durchs Programm. Bei messbasiert geht man grundsätzlich den makroskopischen Weg, hat aber den mikroskopischen gleichzeitig unter die Haube gebracht, da wir es auf dem Zielsystem messen - alles andere „interessiert“ uns nicht.
Wir haben beispielsweise ein taktgesteuertes System gegeben. Welches Schema haben wir in der Vorlesung kennengelernt - was die E-Techniker immer gerne machen?
Wenn Task 2 ein Drittel mal so häufig dran kommen soll wie Task 1?
Fällt dir hier ein Problem auf?
Wir haben bei Task 2 und Task 3 sogenannte „jitter“, es zittert und verhält sich nicht ganz periodisch, da die Tasks nicht immer gleich lang brauchen und die WCET ohnehin nie erreichen.
Hier kann man die jeweiligen Tasks abmessen, und dann die „Restzeit“ warten, um die Lücke zu füllen.
Passt dann nicht alles mit der Busyloop?
(Er hat dann noch Termine angesprochen, und wo man die hier in diesem Codebeispiel messen könnte.)
Nach den jeweiligen Tasks kann man die Terminabfrage einbauen.
(Hier ist das Problem, dass wir verpasste Termine erst im NACHHINEIN erkennen - somit wird die eventuell anstehende Ausnahmebehandlung viel zu spät eingeleitet!)
Gut, wir haben nun gemerkt, dass die Busyloop nicht das Allheilmittel ist. Was können wir denn dann verwenden, sagen wir in einem taktgesteuerten System?
(Ich habe Rahmen angesprochen, da es in älteren Protokollen oft drankam, weshalb ich auch nicht alles ausführen werde. Rahmenlänge, Hyperperiode teilen, groß genug für max. Ausführung, klein genug für min. Periode etc.)
Was passiert denn, wenn ein Rahmen, in dem 2+ Tasks eingelastet wurden, gesprengt wird - angenommen wir haben die WCET falsch ausgerechnet, welcher Task war denn daran schuld - können wir wissen, welcher Task seinen Termin eingehalten hat und welcher nicht?
(Wenn drei eingelastete Tasks den Rahmen sprengen, ist es anscheinend unmöglich zu wissen, welcher Task „schuld“ war und welche Tasks nun betroffen sind von der Terminverletzung. Daher Problem: man muss für alle Tasks die Ausnahmesituation einleiten!)
(Es wurde auch noch kurz angemerkt, dass ein so ein Rahmen praktisch eine „Busyloop“ ist, da alle Tasks sequenziell ausgeführt werden.)
(Zusätzlich wurde betont, dass nur Aufgaben, die VOR dem Rahmenanfang ausgelöst werden, da eingelastet werden können - diese Ereignisse kommen als Signale rein. Stichwort „Rangfolge“)
(Nach der letzten Frage unten wurde noch angemerkt, dass der Rahmen eigentlich nichts anderes ist als ein periodischer Zusteller mit „vollem Budget“)
Bisschen Zeit haben wir noch. Jetzt hatten wir nur periodische Aufgaben. Was fallen dir denn für Methoden zur Abarbeitung von nicht periodischen Aufgaben ein? Was bedeuten diese überhaupt, gibt es unterschiedliche?
Es gibt die aperiodischen und sporadischen.
aperiodisch: weicher/fester Termin, sporadisch: harter Termin
Diese werden durch Signale ausgelöst, die asynchron zur Laufzeit auftreten - oft bedingt durch die physikalische Umwelt.
Man kann sie im Unterbrecherbetrieb oder Hintergrundbetrieb abarbeiten.
Unterbrecherbetrieb: schnelle Antwortszeit der nicht periodischen Aufgabe, aber periodische Aufgaben werden verzögert.
Hintergrundbetrieb: periodische Aufgaben laufen durch, der „Idle Task“ arbeitet die anderen ab.
Unterbrecherbetrieb wird oft hergenommen, wenn die periodischen Aufgaben keine harten Deadlines haben und es sporadische Aufgaben gibt.
Andersherum dann lieber Hintergrundbetrieb.
Kennen Sie noch andere Methoden?
Kurz Slack-Stealing angesprochen: Kompromiss zwischen beiden - periodische Aufgabe wird hinten angestellt, wenn diese danach noch rechtzeitig fertig werden kann. (Hier auch kurz angesprochen, dass wir das Einlastungsverfahren des obengenannten Rahmens gut wiederverwenden können)
Periodischer Zusteller:
Bei Anfang der Auffüllperiode wird geguckt: gibt es Tasks? ja → arbeiten. nein → budget = 0
Problem: Task, der kurz nach Auffüllperiode ankommt, muss bis zur nächsten Periode warten.
Also?
Aufschiebbarer Zusteller: Behält Budget über die Periode hinweg.
Problem: Double Hit - Tasks, die an der Grenze der Auffüllperiode auftauchen, lösen Doppeltreffer aus: kurz davor wird das Budget des Zustellers verbraucht und bekommt unmittelbar nochmal Budget → weist in der Zeit kein periodisches Verhalten auf und verletzt evtl. Zeitresktriktionen anderer Aufgaben.
Wunderbar. Und dass du den SpSL Sporadic Server verstanden hast, glaube ich dir!