Startseite > Embedded > Software > Rezepte fürs Bugfixing

Fünf Ursachen für unliebsame Firmware-Fehler

Rezepte fürs Bugfixing

23. Oktober 2015, 12:59 Uhr | Michael Barr

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 3

Prioritätsinversionen

Wenn zwei oder mehr Tasks ihre Arbeit mit Hilfe einer singulären Ressource koordinieren oder auf andere Weise teilen, können mehrere unliebsame Probleme auftreten. Weiter oben sind mit Race Conditions und nicht ablaufinvarianten Funktionen bereits zwei häufig vorkommende Task-Sharing-Probleme beschrieben. Als nächstes soll es um die Prioritätsinversion gehen, deren Reproduktion und Eliminierung sich ebenso schwierig gestalten kann.

Das Problem der Prioritätsinversion geht auf die Verwendung von Betriebssystemen mit festgelegten relativen Task-Prioritäten zurück. In einem solchen System muss der Programmierer jeder Task eine Priorität zuweisen. Der im RTOS enthaltene Scheduler gewährleistet, dass die Task mit der höchsten Priorität zu jeder Zeit die CPU nutzen kann. Hierzu kann der Scheduler eine Task mit geringerer Priorität während ihrer Verarbeitung jederzeit unterbrechen. Gelegentlich aber können Ereignisse, die außerhalb der Kontrolle des Schedulers liegen, die Task mit der höchsten Priorität an der Verarbeitung hindern, sodass kritische Deadlines verpasst werden oder das System versagt.

Jobangebote+ passend zum Thema

Sales Manager / Vertriebsmitarbeiter (m/w/d)

Verifysoft Technology GmbH, Offenburg

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Das Auftreten einer Prioritätsinversion setzt die Existenz von mindestens drei Tasks voraus. Die Tasks mit der höchsten und der niedrigsten relativen Priorität teilen sich eine Ressource beispielsweise mit Hilfe eines Mutex. Eine dritte Task soll eine Priorität besitzen, die zwischen den beiden anderen liegt.

Dieses Szenario ist in Bild 2 illustriert. Zum Zeitpunkt t1 greift die Task mit der niedrigen Priorität auf die geteilte Ressource zu. Nachdem die Task mit hoher Priorität diejenige mit der niedrigsten Priorität unterbrochen hat, schlägt ihr Versuch, zum Zeitpunkt t2 auf die geteilte Ressource zuzugreifen fehl, weil die Ressource noch von der niederprioren Task blockiert ist. Also gibt der Scheduler die Kontrolle über die CPU an die niederpriore Task zurück, damit diese die Ressource frei machen kann. Schließlich kommt es dazu, dass die Task mittlerer Priorität, die kein Interesse an der von der nieder- und der hochprioren Task gemeinsam genutzten Ressource hat, zum Zeitpunkt t3 die niederpriore Task unterbricht. In diesem Moment kehren sich die Prioritäten um: Die mittelpriore Task kann die CPU beliebig lange nutzen, während die hochpriore Task auf die niederpriore Task wartet. Es kann hier sogar mehrere Tasks mittlerer Priorität geben.

Abhilfe: Mit einer einfachen, drei Schritte umfassenden Methode können Sie das Auftreten von Prioritätsinversionen in Ihrem System vermeiden. Entscheiden Sie sich erstens für ein RTOS, das in seinem Mutex-API Mittel gegen Prioritätsinversion enthält. Diese werden meist als Prioritätsvererbungs-Protokoll oder Priority Ceiling Emulation bezeichnet. Verwenden Sie zweitens nur das Mutex-API für die Absicherung geteilter Ressourcen in Echtzeit-Software. Berücksichtigen Sie drittens die zusätzliche Verarbeitungszeit, wenn Sie eine Analyse für den Nachweis durchführen, dass alle Deadlines eingehalten werden.