Mobile-Menu

Queuing – Warteschlangentheorie für Embedded-Software

Seite: 12/12

Beispiel 4: Antwort auf Interrupts mit hoher Priorität

Interrupts kommen sporadisch aus einem Hardware-Device an, mit einer mittleren Zwischenankunftszeit M = 400 Mikrosekunden. Für diese Interrupts beträgt die mittlere Verarbeitungszeit A = 300 Mikrosekunden.

Was ist die mittlere Antwortzeit für die Verarbeitung dieser Interrupts?

Die mittlere Verweilzeit einer Message in einer Queue erhalten wir mit der Formel Tavg = A / (1-R).

Somit beträgt die mittlere Zeit Tavg = 300 / (1-300/400) = 1200 Mikrosekunden.

Das ist die mittlere Zeit, bis die Software ihre Antworten auf diese Interrupts bearbeitet.

Ein solches Ergebnis wirft etliche Fragen rund um den System- und Softwareentwurf auf:

  • Kann unsere Applikation mit eine Antwortzeit umgehen, die viel länger ist als die mittlere Interrupt-Rate und viel länger als die Interrupt-Datenverarbeitungszeit?
  • Wo werden die Interrupt-Daten gespeichert, während sie auf ihre Verarbeitung warten?
  • Wird dieser Speicher in Software oder Hardware implementiert?

Versuchen wir, diese Fragen mithilfe der ersten hilfreichen Formel zu beantworten. Würden Interrupts in einer Queue auflaufen, dann ergäbe sich die die mittlere Länge der Queue aus unserer Formel Lavg = R / (1-R).

In diesem Beispiel ist das Ergebnis Lavg = (300/400) / (1-300/400) = 3 Messages. (Dieses Ergebnis erzielen Sie auch mithilfe des Little-Theorems). Und !! … Für das Handling in diesem Hardware-Device müssen also Interrupts bzw. Interrupt-Daten in Queues auflaufen können.

Die Ergebnisse aus der Berechnung der mittleren Queue-Länge führen uns zu der dritten der eben gestellten Fragen. Wird dieser Speicher in Software oder Hardware implementiert? Manche Prozessoren, zum Beispiel solche zur Netzwerk-Kommunikation, bieten bereits integrierte Message-Queuing-Funktionalität für Onchip-Hardwareschnittstellen.

Soll diese Queue aber in Software implementiert werden, müssen wir die Software dieses besagten Hardware-Devices redesignen, um Interrupt-Overload-Verluste wie im Beispiel 3 beleuchtet zu vermeiden. Die Datenverarbeitung (A = 300 Mikrosekunden) erfolgt nicht mehr vollständig direkt in der Interrupt-Service-Software, sondern wir müssen die Software stattdessen in eine sehr kurze Interrupt-Service-Routine und eine separate Software-Task aufteilen, die den Großteil der Interrupt-Daten verarbeitet. Die Interrupt-Service-Routine leitet Messages (eine je Interrupt) über eine Message-Queue an die Software-Task weiter, wie in Abbildung 7 gezeigt.

Wir sehen hier also, wie eine schnelle Queuing-Überschlagsrechnung uns dazu veranlassen kann, die eine oder andere Entscheidung beim Entwurf von Embedded-Systemen und -Software zu überdenken.

Resümee: Wie geht es weiter?

Der Begriff „Warteschlangentheorie“ lässt auf viel trockene Theorie schließen, doch bietet diese Methode hohen praktischen Nutzen für den Entwurf von Embedded-Systemen und -Software. In die Warteschlangentheorie lässt sich natürlich noch tiefer einsteigen. Nicht ohne Grund ist sie ein anerkannter Zweig der klassischen Mathematik.

* David Kalinsky ist Berater, Trainer und Dozent für Echtzeit- und Embedded-Programmierung in Sunnyvale/Kalifornien (USA)

(ID:44833511)

Weiterführende Inhalte