Bugs und Defekte in Multitasking-Software eliminieren

Anbieter zum Thema

Schutz vor Multitasking-Fehlern

Seit einiger Zeit werden statische Analysetools vermehrt in RTOS-Taskingmodellen eingesetzt. Sie eignen sich damit auch für das Auffinden von Multitasking-Fehlern, die beim Einsatz eines RTOS oft auftreten können, wie Race Conditions, Task Blocking, Deadlocks, Lockouts. Eine Race Condition ist eine Wettbewerbssituation, die auftritt, wenn Tasks ohne Locking-Mechanismus auf gemeinsame Daten zugreifen, wie in Abbildung 2 dargestellt.

Die Task-„Anzeige” muss hier ausgeführt werden und greift auf den gemeinsamen Datenbereich zu, der gerade von der Task „Messung“ beschrieben wird. Beim Ausführen der Software kann dies sporadische Datenkorruptionen verursachen. Es kommt zu einer sogenannten Race Condition, hier dargestellt als Anzeigefehler: In einer Abfolge von Anzeigewerten von 100 und 99 erscheint ein Wert von 199.

Ein statisches Analysetool überprüft in diesem Fall den Sourcecode auf Daten, auf die mehrere Tasks zugegriffen haben, von denen mindestens eine ein Schreibvorgang war. Das Tool prüft, dass das Lesen und Schreiben nicht als atomare Operationen stattfindet. Dann wird der Code für alle diese Datenbereiche nochmals durchsucht, um herauszufinden, welches Software-Lock vor dem Zugriff auf diese Daten normalerweise gesperrt und nach dem Zugriff wieder freigegeben wird.

Das Lock bezeichnet man in diesem Fall als „Bewacher“ der Daten. Anschließend wird der Code nochmals durchsucht, um herauszufinden, wo Zugriffe auf diese Daten möglich sind, also wo der „Bewacher“ die Daten nicht ausreichend schützt. Fehler dieser Art werden als Softwaredefekt angezeigt.

Ein weiterer Gleichzeitigkeitsfehler, den viele statische Analysetools beheben können, ist das Task Blocking: Eine Task hält über einen langen Zeitraum ein Lock, wodurch eine Task höherer Priorität sehr lange blockiert wird. Es handelt sich dabei um eine Variante der Prioritätsinversion. Abbildung 3 zeigt ein Beispiel mit POSIX.

Andere Tasks (POSIX-Threads) höherer Priorität, die den Mutex sperren wollen, könnten in diesem Beispiel bis zu drei Sekunden blockiert werden. Dies ist natürlich eine verhältnismäßig einfache Form der Prioritätsinversion und weit entfernt von der automatischen Identifizierung einer „unbegrenzten Prioritätsinversion“ - ein viel subtileres Phänomen, doch ein gravierender Software-Designfehler.

Mit statischer Analyse lassen sich auch verschiedene Arten von Task-Deadlocks erkennen; beispielhaft in Bild 4 dargestellt.Wenn die Software tatsächlich ausgeführt wird, tritt die Verklemmungssituation vielleicht nur selten auf, doch ein statisches Analysetool erkennt bei jeder Analyse das Deadlock-Potential. Das Tool sucht erst nach einer zirkulären Abhängigkeit zwischen Tasks und anschließend nach einer inkonsistenten Reihenfolge von gemeinsamen Locks, welche die Tasks miteinander verbinden.

Auch eine vierte Klasse von Gleichzeitigkeitsfehlern lässt sich mit statischer Analyse auffinden, die sogenannten Lockouts. Abbildung 5 zeigt einen typischen defekten Code.

Wenn diese Task (‘Thread’) vergisst, ihr Lock wieder freizugeben, müssen andere Tasks für unbestimmte Zeit darauf warten. Die Task selbst könnte sogar blockiert werden, wenn sie später versucht, das Lock wieder zu verwenden.

Statische Analysetools können heute schon etliche Multitaskingfehler entdecken und werden in der Zukunft sicher noch effizienter arbeiten. Das Auffinden von nur einer Race Condition, einem Deadlock oder einem Lockout könnte die Ausgaben für ein statisches Analysetool rechtfertigen, wenn man den enormen finanziellen und zeitlichen Aufwand für das Aufspüren solcher Defekte mit herkömmlichen Test- und Debugtools betrachtet.

Ergänzendes zum Thema

Expertenmeinung des Autors

Statische Analysetools der neuen Generation sind mittlerweile in der Lage, Multitasking-Fehler zu erkennen, die häufig beim Einsatz von Echtzeitbetriebssystemen (RTOS) auftreten. Mit herkömmlichen Softwaretest-Methoden lassen sich diese Fehler nur schwer auffinden, da sie sporadisch und unregelmäßig auftreten. Statische Analysetools entdecken diese Fehler deterministisch. Ihr Einsatz in diesem Bereich steckt jedoch noch in den Kinderschuhen, denn bislang können sie nur wenige der unzähligen Multitasking-Fehler erkennen. In den nächsten Monaten sollte man die Weiterentwicklung der statischen Analysetools im Auge behalten und die Tools um richtigen Zeitpunkt in die Entwicklungsumgebungen für Embedded-Echtzeitsoftware integrieren.

Quellen und Literaturhinweise:

[1] Boehm, B.: Software Engineering Economics, 1981, ISBN: 0138221227

[2] DO-178B, „Software Considerations in Airborne Systems and Equipment Certification“, RCTA, December 1992.

Überblick: Schema eines einfachen Prozesses für den Einsatz statischer Analysetools bei Security-Audits und anschließenden Verbesserungen der Sicherheit. Am Anfang sollte eine ausführliche Bedrohungsanalyse stehen. Daraus ergibt sich dann der Einsatz der Tools. (GrammaTech)

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

(ID:44759460)