Eine Anwendung erfordert das Einhalten von Deadlines im Bereich von Milli- oder gar im Mikrosekunden? Linux bietet gleich mehrere Möglichkeiten, um derartige Echtzeitanforderungen zu erfüllen .

Echtzeit ist eine Frage der Rechtzeitigkeit, keine der Schnelligkeit. Solange das System alle zeitlichen Anforderungen, die so genannten Deadlines, einhält, spielt es keine Rolle, ob Reaktionen innerhalb einer Sekunde oder einer Millisekunde erfolgen. Trotz dieser Definition hat es sich aber eingebürgert, dass Anwender von Echtzeitsystemen Worst-Case-Latenzen im Mikro- oder zumindest im unteren Millisekundenbereich erwarten.

Unter Latenzzeit versteht man jene Zeit, die zwischen dem Auslösen eines Ereignisses (Interrupt) und dem Start der zugehörigen Interrupt-Service-Routine (Interrupt-Latenzzeit) oder des Rechenprozesses (Prozess-Latenzzeit) vergeht. Bei strenger Auslegung muss der Hersteller nachweisen, dass sein Echtzeit-Betriebssystem die von ihm angegebene Latenzzeit unter allen Umständen einhält.

Dieser Nachweis fällt allerdings (nicht nur im Linux-Umfeld) ausgesprochen schwer. Bei komplexen Betriebssystemen wird er daher weniger wissenschaftlich als vielmehr ingenieursmäßig geführt: Man setzt das System unter Höchstlast und misst die Zeiten einfach aus. Eine ausreichend lange Messzeit vorausgesetzt, wird der Worst Case, der Fall, bei dem die größten Latenzzeiten auftreten, wohl eintreten. Hoffentlich!

Da früher ein Standard-Linux-Kernel harte Echtzeitanforderungen (es gibt kein Pardon für zeitliche Ausrutscher) im Mikrosekundenbereich nicht erfüllen konnte, setzten und setzen viele Entwickler auf einen Dual-Kernel-Ansatz: Sie kombinieren den Linux-Kernel mit einem Echtzeit-Kernel (siehe Abbildung 1).

Abbildung 1: Dual-Kernel-Ansatz: Linux als Idle-Task eines Echtzeit-Kernels, der die Hardware steuert. Der Datenaustausch zwischen beiden Teilen erfolgt über Message-Queues.

Zwei Herzen in der Brust

Der Echtzeit-Kernel steuert bei dieser Kombination die Hardware, insbesondere das Sperren und Freigeben von Interrupts. Damit sitzt er, logisch betrachtet, unterhalb des Linux-Kernels, und Linux wird zur Idle-Task dieses zweiten Betriebssystems. Das hat etwas von einem echtzeitfähigen Hypervisor.

Die technische Realisierung einer solchen Lösung, das Hijacken der Interrupts, ist gar nicht kompliziert. Für den Entwickler, der den zusätzlichen Echtzeit-Kernel nutzen möchte, bedeutet dies, dass er seine Software in zwei Teile aufteilt, nämlich in die Teile, die Echtzeit benötigen, und jene, die das nicht müssen. Letztere realisiert er dann typischerweise als normale Linux-Tasks. Der Datenaustausch zwischen dem echtzeit- und dem nicht echtzeitfähigen Teil passiert über Message-Queues (Fifos) oder über einen gemeinsamen Speicherbereich.

Zwei Rivalen und eine Abspaltung

In der Vergangenheit konkurrierten zwei Ansätze um die Gunst der nach Echtzeit verlangenden Entwickler: Victor Yodaiken ging mit seinem RT-Linux [1] als Erster auf den Markt. Allerdings ließ er sich seinen Echtzeit-Kernel patentieren und komplizierte damit den Einsatz von RT-Linux in kommerziellen Lösungen. Yodaiken verkaufte sein Patent und alle (Marken-) Rechte von RT-Linux im Februar 2007 an die Firma Windriver [2].

Aufgrund der in Europa verbreiteten Vorbehalte gegen das Patent und damit gegen RT-Linux hat Paolo Mantegazza von der Technischen Universität Mailand RTAI (Realtime Application Interface, [3]) entwickelt, das hierzulande starke Verbreitung gefunden hat.