Dann entschuldige ich mich für die kurze Verspätung und dann würde ich sagen, legen wir auch gleich los.

Wir haben heute ein volles Programm.

Letzte Woche haben wir uns damit beschäftigt, wie man nicht-päodische Aufgaben sinnvoll in so ein Echtzeitsystem reinbringen kann.

Ich hatte im Prinzip damit aufgehört, dass wir eigentlich drei oder vier Varianten kennengelernt haben.

Das war der Hintergrundbetrieb, das war die Geschichte, mit der wir nicht-päodische Aufgaben immer dann ausführen, wenn wir gerade Zeit haben.

Das ist an sich schick, weil wir damit die periodischen Aufgaben in keinster Weise beeinflussen, was den Vorteil hat, dass wir bei unserer etablierten Planungstheorie bleiben können.

Das heißt, die Planbarkeitsanalyse bleibt nach wie vor einfach, hat natürlich den riesengroßen Nachteil, dass es eigentlich nicht für sporadische Aufgaben geeignet ist.

Also da noch mal zur Erinnerung, apäodische Aufgaben waren nicht-päodische Aufgaben mit weichem oder festem Termin und sporadische Aufgaben sind dann die mit hartem Termin.

Nicht-päodisch ist einfach der Oberbegriff.

Hintergrundbetrieb ist also schlecht, auch schlecht für die nicht-päodischen Aufgaben, was die Anbordsat angeht.

Gleiches galt für diese erste, etwas ausgefuchstere Technik, die wir uns angeguckt haben, das waren diese periodischen Zusteller.

Wir haben uns letztes Jahr die einfachste Variante davon angeguckt, das war der abfragende Zusteller.

Also der, der nachguckt, ist eine nicht-päodische Aufgabe da, wenn ja, führe ich sie aus, wenn nein, dann lege ich mich schlafen und mein Budget ist weg.

Dann haben wir uns noch den Vordergrundbetrieb angeguckt, das war eigentlich die Geschichte mit, ja, wir implementieren die Aufgabe, die nicht-päodische Aufgabe einfach als Interrupt oder innen Interrupt-Händler,

beziehungsweise alternativ als höchstprioriere Aufgabe, dann hat den riesen Nachteil, dass wir dann nicht mehr sagen können, ob die periodischen Aufgaben ihre Termine einhalten.

Ist also nicht unbedingt so toll, was die Planbarkeitsanalyse angeht.

Wir haben uns noch den Schlupf-Deep, also das Slack-Stealing angeguckt.

Das ist eine schöne Technik, ist im Allgemeinen aber zu komplex.

Das heißt, die Frage, die sich für uns eigentlich heute stellt, ist, irgendwie müssen wir jetzt aus diesem Dilemma raus.

Also eigentlich wollen wir die periodischen Aufgaben nicht beeinflussen, wir wollen trotzdem eine gute Antwortzeit für die nicht-päodischen Aufgaben haben und natürlich geht das auch.

Man kann also noch mehr tun, als das, was wir uns letzte Woche angeguckt haben.

Und der Schlüssel des Ganzen liegt darin, dass wir dem Zusteller ermöglichen müssen, dass er sein Budget behalten darf.

Weil das war ja letzte Woche das Problem.

Er verliert sein Budget, beim Nachgucken ist nichts da, Budget ist weg.

Nicht unbedingt das, was man sich darunter vorstellt, weil man hat ihm dieses Budget ja zugesprochen. Also warum soll er es denn nicht verwenden können?

Und das gucken wir uns heute an.

Gibt es ausgefuchstere Varianten von diesen Zustellern, die genau das können.

Die unterscheiden sich im Wesentlichen dann durch diese Auffüll- und Verbrauchsregeln und da gucken wir uns halt mal an, wie das aussieht.

Was wir letzte Woche auch angerissen haben, war diese Sache mit dem Akzeptanztest.

Also die Frage, was mache ich eigentlich mit einer sporadischen Aufgabe? Die hat ja einen harten Termin.

Und ja, ich muss den harten Termin ja genauso garantieren, wie ich ihn für eine periodische Aufgabe garantieren muss.

Das kann ich im Allgemeinen nicht, weil ich weiß ja nicht, wann diese sporadische Aufgabe auftritt.

Das heißt, wir haben dann gesagt, okay, wir müssen eine Übernahmeprüfung machen.

Also der Scheduler muss jetzt testen und prüfen, kann ich diese sporadische Aufgabe einplanen.

Und zwar so, dass sie bis zu ihrem Termin fertig wird. Heute gucken wir uns mal an, wie sowas konkret aussehen kann.

Genau. Der Fokus heute liegt konkret auf den Ereignisgestördensystem.

Also grundsätzlich ist es zumindest vorteilhaft, wenn man sowas in den Ereignisgestördensystem einbaut.

Das heißt jetzt nicht, dass ich nicht auch dieselben Mechanismen in einem Zeitgestördensystem verwenden kann.

Nur macht es da an vielen Stellen wesentlich weniger Sinn.

Wir haben ja gesagt, wir haben keine Onlineplanung, wenn wir also selbe Konzepte einsetzen wollen,

wir müssen da eigentlich wieder Planung einsetzen und also eine Online-Scheduler einbauen in unser System,

was ja eigentlich die Grundidee von einem zeitgesteuerten System verwässert.

Nichtsdestotrotz kann man das natürlich machen.

Ganz am Ende werde ich dann nochmal über das Konzept des hierarchischen Schedulings reden.

Also sprich der Idee näher, wir können eigentlich verschiedene Konzepte auf verschiedenen Ebenen einsetzen.

Also wir können Aufgaben bauen, die auf der obersten Ebene eben mit statischen Prioritäten versehen sind

und innerhalb dieser Aufgaben kann man dann aber wieder andere Planungsverfahren nehmen.

Für diejenigen, die sich dann gerne zum Beispiel mit Linux oder ähnlichen Betriebssystemen rumschlagen,

da wird ja dann oft davon geredet, man soll irgendwas im User-Land implementieren.

Das heißt letztendlich nicht im Betriebssystem.