Eignung von L4 für Realtime-Zwecke

• (+) Da Interrupts und Anwendungsthreads gemeinsam gescheduled werden, können Interruptbehandlungsroutinen oder Geträtetreiber nicht die Einhaltung von Zielzeiten beeinflussen
  Herkömlich sperren Treiber für unbestimmte Zeit Interrupts oder füllen eine Warteschlange aufgeschobener Arbeiten, die dann zu unbestimmten Zeten abgearbeitet werden.
  Szenario: Überlastung des Systems durch Interrupts, so dass System für nichts mehr anders Zeit hat: Nach der Behandlung des Interrupts entscheidet der Interrupthandler - nicht der Microkern, ob und wann der nächste Interrupt behandelt wird. Im Fall, das der Interrupthandler zu lange braucht, weil er mit der Überlast nicht umgehen kann, kann er noch durch das Scheduling verdrägt und damit gedrosselt werden.
• (?) Interruptbehandlung erfolgt auf Nutzerebene. Dieses kostet leider minimal einen Overhead, den sich das Anwendungssystem leisten können muß
  (Aufwand aber geringer als normale IPC.
  Die Kernverdrängbarkeit (d.h. die Arbeit im Kern wird zugunsten eines horchprioren Interrupts unterbrochen):
  L4Ka (Pistacio ?) sperrt Interrupts im Kernmode, da die Zeit ohnehin sehr kurz ist. (Ausnahme: unmapping).
  Fiasco hat explizite Verdrängungspunkte im Register-IPC Die Unverdrägbarkeit bis auf wenige Verdrängungspunkte im Kern ist wichtig für den formalen Korrektheitsberweis.
• (+) User-level Tasks einschließlich Treiber und Handlers können nur die ihnen zugeteilten Interrupts kontrollieren, aber nicht fremde Interrupts maskieren. Daher ist kein Vertrauen nötig, auch nicht zeitweise.
  Gerätetreiber und Interrupthandler arbeiten mit normalen Koordinierungsmechanismen, die unschädlich für die Verdrängung oder für Interrupt sind, d.h. keine Spinlocks, keine Interruptsperren
  → Koordinationsmaßnahmen beschränken sich auf lokale effekte und stören nicht unvorraussagbar die Rechtzeitigkeit (timelineness) anderer Komponenten oder tragen zur Gesamtverzögerung bei
• (-) Die extremen IPC-Optimierungen (genauer?) verkomplizieren das Echtzeitscheduling, allerdings kann auf sie bei geringen Performanceeinbußen verzichtet werden.
  Problem: Priority Inversion kann auftreten,wenn ein hochpriorer Thead einen niederprioren Thread per IPC anspricht.
• Im IPC wird die Kontrolle an einen anderen Thread übergeben (direct process switch), und damit eine Scheduling Entscheidung getroffen, ohne den Scheduler zu fragen.
  Der blockierte Aufrufer wird nicht aus der Ready-Liste genommen, um Zeit zu sparen (lazy scheduling). Erst wenn der Scheduler den lauffähigen Thread mit der höchsten Priorität ermittelt, und einen blockierenden Thread vorfind, wird er in die Warteschlange eingefügt.
• (+) Mit den User-Level-Pagers können explizit Seiten im Speicher gehalten werden, die Informationen enthalten, die sofort verfügbar sein müssen (time sensitive)
• (-) Der Scheduler ist im Kern fest eingebaut, zusammen mit dem IPC-Thema muß der Designer aufpassen.
• Hauptaugenmerk bei L4 sind Geschwindigkeit, Kompaktheit und Einfachheit. Wie sieht es mit der Einhaltung von Zeitschranken (timelineess) und der Vorhersagbarkeit (predictability) aus ?

[Ruocco2008] zu Fiasco:

• preemtable durch wait-free und lock-free Koordinierung
• löse viele hier angesprochenen Echtzeitprobleme
• (-)höhere Kernkomplexität
• (-)IPC-Zusatzaufwand, der nicht ganz quantifiziert wurde
• Priority Inheritance wird durch Erweiterung des Schedulingmechanismus um die Möglichkeit Prioritäten mit Schedulingkontexten über Tasks hinweg zu migrieren

• hat Scheduling Framework für periodische Echtzeittasks mit bekannten Ausführungszeitverteilungen

L4-embedded (OKL4 ?)

• hat Asynchrone Notifikation: diese ist nicht blockierend,benachrichtet einen Thread annonym von einem Ereignis
• hat die Timeouts bei IPC entfernt und Systemlock. Dies mach IPC einfacher und schneller. Die genaue Zeitbestimmung muß der Userlevel machen.

timeslice donnation

priority inversion

priority inheritance

kernel preemptability

Lösungsmöglichkeiten für priority-Inheritance

Fiasco übernimmt bei IPC auch einen Scheduling-Kontext

Elphinstone (uni SW) schlägt die statische Strukturierung der Threads und ihrer Prioritäten vor, dass Priority-Inversion unmöglich wird. Das passt gut zum statischen L4-Scheduler

Man sollte den Ablauf so aufteilen, dass die ganze kritische Sektion in einem Server-thread n möglichst hoher Priorität läuft

Abgrenzungen

Abgrenzung zu QNX und Integrity von [Ruocco2008]: ausschließiger Zweck für eingebettete Anwendungen, sie sind nicht als Fundament eines Betriebssystem gedacht.

Mechanismen von L4 (Pistacio):

KernelInformationPage: ClockInfo

• Timeout und SleepZeiten sind Prozessorabhängig bis zu 2ms
• Intel x86_32 hat den TSC

Wichtige Anwendungen

• Multimedia-Applikationen bedingen sowohl hoch dynamische Echt-Zeit-Last als auch Nicht-Realtimelasten, die Betriebsmittel wie Rechenkerne, Platten, Videosubsysteme un Netzwerke gemeinsam nutzen. Diese Mischung ist in den 1995er Jahren neu [HR2006]
  Die Lögung wurde durch Middleware versucht - Nach [HR2006] kann aber nur das Betriebssystem sauber zwischen Realtime und Nicht-Realtime trennen und den Real-TimeAnwendungen verlässliche Garantien für Betriebsmittel geben.

Literatur:

[HR2006] H.H.,M.R.: "Ten Years of Research on L4-Based Real-Time Systems" 2006

Beschreibt DROPS mit DoPe