Suchen

Echtzeitbetriebssysteme – Einführung und Konzepte

Seite: 2/4

Firmen zum Thema

Task Switching mit vorgegebenem Timing

Bild 4: Zeitverhalten beim Task Switching.
Bild 4: Zeitverhalten beim Task Switching.
(Bild: Kalinsky Associates)

Die Zeit, die das Task-Switching in Anspruch nimmt, ist bei der Evaluierung eines Betriebssystems zu berücksichtigen. Manche einfachen Betriebssysteme (nicht präemptiv) führen das Task-Switching nur bei Timer-Ticks aus; diese können z.B. 10 Millisekunden auseinanderliegen. Ist ein Task-Switch innerhalb dieser Zeitspanne von 10 Millisekunden erforderlich, würde er erst am Ende der aktuellen Zeitspanne stattfinden. Eine solche Verzögerung wäre bei den meisten Embedded-Echtzeit-Systemen nicht akzeptabel.

Komplexere präemptive Task-Scheduler müssen häufig Task-Arrays durchsuchen, um festzustellen, welche Task als nächstes auszuführen ist. Je mehr Tasks zu durchforsten sind, desto länger dauert die Suche. Die meisten normalen Betriebssysteme gehen so vor und sind daher nicht deterministisch.

Echtzeitbetriebssysteme dagegen vermeiden solche Suchvorgänge und verwenden stattdessen inkrementell aktualisierte Tabellen, anhand derer der Task-Scheduler erkennt, welche Task als nächstes auszuführen ist. Diese beiden unterschiedlichen Zeitverhalten werden im Bild 4 dargestellt.

Die notwendige Zeit beim Task Switching nimmt zu, je mehr zu planende Tasks ein Softwaresystem enthält. Die tatsächlich für ein Task-Switch erforderliche Zeit ist jedoch nicht die Zeit, die mit der roten Strichlinie dargestellt wird. Sie könnte bei anderen Task-Switch-Vorgängen auch darüber oder darunter liegen. Die schattierten Bereiche um die rote Strichlinie herum zeigen nur an, mit welcher Wahrscheinlichkeit die tatsächliche Task-Switch-Zeit so weit über oder unter der roten Strichlinie liegt.

Die gerade grüne Linie dagegen stellt die Eigenschaft der Task-Switch-Zeit in einem Echtzeitbetriebssystem dar. Sie ist konstant und unabhängig von Lastfaktoren, z.B. Anzahl von Tasks in einem Softwaresystem.

In manchen Fällen, wie z.B. im linken Bereich der Grafik, kann die Task-Switch-Zeit bei normalen Betriebssystemen auch schneller sein als bei Echtzeitbetriebssystemen. Trotzdem eignen sich Echtzeitbetriebssysteme besser für den Einsatz in Embedded-Echtzeit-Applikationen. Letztlich steht der Begriff „Echtzeit“ nicht für „schnellstmöglich“. „Echtzeit“ erfordert stattdessen ein konsistentes, wiederholbares und bekanntes Zeitverhalten. Bei einer kleinen Anzahl an Tasks führt ein normales Betriebssystem den Task-Switch vielleicht schneller aus, doch kann schon beim nächsten Ausführen desselben Task-Switch eine längere zeitliche Verzögerung auftreten.

Der Vorteil eines Echtzeitbetriebssystems ist seine bekannte und reproduzierbare Timing-Performance, die meist auch schneller ist als die eines nicht-deterministischen Task-Schedulers, wenn sich viele Tasks in einem Software-System befinden. In den meisten Fällen sind die Task-Switch-Zeiten eines Echtzeitbetriebssystems viel schneller als in einem normalen Betriebssystem, wenn mehr als 5 oder 10 Tasks vorliegen.

Bild 5: Message-Kommunikation zwischen Tasks
Bild 5: Message-Kommunikation zwischen Tasks
(Bild: Kalinsky Associates)

Intertask-Kommunikation und -Synchronisation in Echtzeitbetriebssystemen

Die meisten Betriebssysteme, auch Echtzeitbetriebssysteme, bieten verschiedene Mechanismen zur Kommunikation und Synchronisation zwischen Tasks an. Diese Mechanismen sind in einer präemptiven Umgebung mit vielen Tasks erforderlich, ansonsten könnten die Tasks beschädigte Daten kommunizieren oder sich gegenseitig behindern.

Beispielsweise könnte eine Task verdrängt werden, während sie gerade eine Datentabelle aktualisiert. Wenn die andere Task, welche die erste Task verdrängt hat, dann die Tabelle liest, greift sie auf Bereiche zu, die gerade aktualisiert wurden, sowie auf Bereiche, die noch nicht aktualisiert wurden. Dies könnte zu inkorrekten oder nicht plausiblen Ergebnissen führen. Beispiel: Eine Datentabelle mit Temperaturmessungen beginnt mit dem Inhalt „10 C”.

Eine Task beginnt, diese Tabelle zu aktualisieren und schreibt den neuen Wert „99 F“ Zeichen für Zeichen in die Tabelle. Wird diese Task mitten in der Aktualisierung verdrängt, könnte die verdrängende Task dann einen Wert wie „90 C“, „99 C“ oder „99 F“ lesen, je nachdem, an welcher Stelle die erste Task verdrängt wurde. Die teils aktualisierten Werte sind definitiv nicht korrekt und basieren auf komplexen zeitlichen Koinzidenzen, die sich schwer debuggen bzw. konsistent reproduzieren lassen.

In einem RTOS stehen Mechanismen zur Kommunikation und Synchronisation zwischen Tasks zur Verfügung, um solche Fehler zu vermeiden. Die meisten RTOS bieten mehrere Mechanismen an, wobei jeder auf die zuverlässige Übertragung unterschiedlicher Informationen zwischen Tasks optimiert ist.

Die wohl gängigste Kommunikationsmethode zwischen Tasks in Embedded-Systemen ist die Weitergabe von Daten von einer Task an eine andere. Die meisten RTOS bieten hierfür einen Weitergabemechanismus für Messages an, wie im Bild 5 gezeigt. Jede Message kann ein Daten-Array oder gepufferte Daten enthalten.

Bild 6: Message-Weitergabe über eine Message Queue
Bild 6: Message-Weitergabe über eine Message Queue
(Bild: Kalinsky Associates)

Wenn Messages schneller übertragen werden, als sie verarbeitet werden können, stellt das RTOS Message Queues (Warteschlangen) bereit, in denen die Messages auf ihre Verarbeitung warten, wie in Bild 6 gezeigt.

Eine weitere Art der Kommunikation zwischen Tasks in Embedded-Systemen ist die Weitergabe sogenannter „Synchronisationsinformationen“ von einer Task an eine andere. Eine Synchronisationsinformation ist wie ein Befehl; manche Befehle sind positiv und andere negativ. Ein negativer Befehl an eine Task wäre beispielsweise „Bitte jetzt nicht drucken, da meine Task gerade den Drucker verwendet“ bzw. allgemeiner: „Ich will … für den eigenen Gebrauch blockieren“. Ein positiver Befehl könnte lauten: „Ich habe einen Kardionotfall erkannt und bitte um Hilfe bei der Behandlung des Notfalls“ bzw. allgemeiner: „Ich bitte um Unterstützung bei der Behandlung von …“.

Die meisten RTOS bieten einen Semaphore- oder Mutex-Mechanismus zur Behandlung negativer Synchronisation an (auch „Mutual Exclusion“ bzw. wechselseitiger Ausschluss genannt). Mit diesen Mechanismen können Tasks bestimmte Embedded-Systemressourcen für den Eigengebrauch blockieren und nach Fertigstellung wieder freigeben.

Für die positive Synchronisation stehen je nach RTOS verschiedene Mechanismen zur Verfügung, darunter Event Flags oder Signale bzw. die Message- oder Daten-Weitergabe.

Determinismus und schnelle Message-Weitergabe zwischen RTOS-Tasks

Auch bei der Message-Kommunikation zwischen Tasks weisen unterschiedliche Betriebssysteme ein unterschiedliches Zeitverhalten auf. Bei den meisten Betriebssystemen werden Messages zweimal kopiert, wenn sie von Task zu Task über eine Message Queue weitergegeben werden (siehe Bild 6). Im ersten Kopiervorgang wird die Message aus der Message-Sender-Task in einen „geheimen“ RAM-Bereich des Betriebssystems kopiert (Implementieren der Message Queue); dann wird die Message aus diesem „geheimen“ RAM-Bereich kopiert und an die Message-Receiver-Task übermittelt. Das Timing ist dabei nicht deterministisch, denn je länger die Messages sind, desto länger dauern die Kopiervorgänge.

Um diesen nicht-deterministischen Ansatz zu vermeiden und die Performance zu beschleunigen, kann das Betriebssystem einen Pointer (Zeiger) auf die Message kopieren und diesen Pointer an die Message-Receiver-Task übermitteln, ohne dass der eigentliche Message-Inhalt bewegt wird. Um Zugriffskollisionen zu vermeiden, muss das Betriebssystem dann zurück zur Message-Sender-Task gehen und dort die Kopie des Pointers auf die Message löschen. Bei großen Messages entfallen damit zeitaufwändige Kopiervorgänge, und ein deterministisches Zeitverhalten wird sichergestellt.

(ID:44941011)