Die Analyse von Systemereignissen spielt eine wichtige Rolle bei der Echtzeit-Verarbeitung und Performance-Optimierung
Neuer Debugger für die Systemanalyse
Fortsetzung des Artikels von Teil 1
Neuer Debugger für die Systemanalyse
Zum Beispiel kann mit TraceX sichtbar werden, dass bei jedem Empfang eines Datenpakets eine große Zahl von Interrupts generiert wird. Die einfachste und meistverbreitete Lösung ist es, jedes ankommende Paket in eine Warteschlange einzureihen. Je größer allerdings die Zahl der eintreffenden Pakete wird, umso mehr Zeit ist erforderlich, um den gerade laufenden Thread zu unterbrechen und das Paket in die Warteschlange zu legen.
Der System Event Analyzer visualisiert auf einfache Weise den Verarbeitungsaufwand, der durch das Aufreihen der Pakete in der Queue entsteht, und liefert wertvolle Informationen, aus denen der Entwickler die Notwendigkeit ersehen kann, nach Alternativen zu suchen (z.B. Setzen eines Semaphoren bei leerer Warteschlange). Anstatt also den Thread bei jeder Ankunft eines Pakets zu unterbrechen, wird jetzt nur noch dann ein Interrupt ausgelöst, wenn sich keine Pakete mehr im Thread befinden.
Mit TraceX ist es überdies möglich, sich einen Überblick darüber zu verschaffen, wie sich die Prioritätseinstellungen auf die Performance auswirken. Wenn für die Threads eine relativ große Zahl von Prioritätsebenen vergeben wird, kommt es in aller Regel zu einer großen Zahl von Kontextwechseln, damit stets der Thread mit der höchsten Priorität läuft. Wenn Entwickler nicht überlegen, welchen Umfang an Kontextwechseln sie zu tolerieren bereit sind, legen sie den Grundstein für ein potentielles Performance-Problem. Da Kontextwechsel für herkömmliche Debugging-Tools transparent sind, haben Entwickler normalerweise keine Möglichkeit, die Auswirkungen der Prioritätsvergabe zu erkennen.
Jobangebote+ passend zum Thema
TraceX dagegen deckt Kontextwechsel auf und zeigt deutlich, welchen Einfluss sie auf die Performance haben. Was Entwicklern stets auffällt, wenn sie das erste Mal mit einem Tool dieser Art arbeiten, ist die unerwartet große Zahl von Kontextwechseln. Sie sind meist überrascht, wieviel Zeit diese Kontextwechsel verschlingen, und können ihre Programme daraufhin so modifizieren, dass weniger Prioritätsebenen verwendet werden, um die Zahl der Kontextwechsel zu senken. Ohne ein Tool wie TraceX würden den Entwicklern viele Effizienzmängel ihrer Systeme verborgen bleiben.
TraceX liefert also eine von konventionellen Debuggern nicht gebotene grafische Darstellung des Systems. Interrupts, Kontextwechsel und andere System-Ereignisse, die früher nur durch zeitraubende Instrumentierung des Code und mühsames Auswerten der damit eingeholten Daten aufzudecken gewesen wären, werden dem Entwickler nunmehr aussagefähig präsentiert. Wesentlich schneller als mit herkömmlichen Debugging-Werkzeugen allein kann der Entwickler mit TraceX jetzt Bugs finden und beseitigen und die Applikations-Performance optimieren. (Joachim Kroll)
Prioritätsinversionen zu erkennen und zu korrigieren, ist schwierig, denn sie äußern sich meist nur durch mangelhafte Performance, die jedoch viele Ursachen haben kann. Ebenso problematisch ist, dass Prioritätsinversionen möglicherweise durch Testen überhaupt nicht aufgedeckt werden können, was ein nicht-deterministisches Verhalten der Applikation zur Folge hat.
Mit Hilfe des System Event Analyzers ist es relativ einfach, Prioritätsinversionen festzustellen und zu beheben, denn der Trace Buffer gibt eindeutig Auskunft darüber, welcher Thread jeweils läuft. Entsprechend einfach kann man entlang der Zeitachse zurückfahren und prüfen, ob eine Task mit höherer Priorität zur Verarbeitung ansteht. Im nächsten Schritt wird ermittelt, welche Ressourcen-Blockade die Prioritätsinversion ausgelöst hat. Dazu wird in der Regel die Zeitachse im Thread mit der höheren Priorität so weit zurückgespult, bis die letzte Blockierung erreicht ist. Anklicken des betreffenden Events fördert den Mutex bzw. den Semaphoren zu Tage, durch den der wichtigere Thread blockiert wurde. Anschließend kann festgestellt werden, welcher Thread die betreffende Ressource zum fraglichen Zeitpunkt genutzt hat und welches Ereignis niedrigerer Priorität den Semaphoren kontrollierte.
Das einfache Beispiel einer Prioritätsinversion in Bild 3 lässt sich aufdecken, indem in der mit „thread 1“ bezeichneten Zeile das Ereignis „MP“ (Mutex Put) angeklickt wird. Unter „Selected Event“ erscheint daraufhin eine geplante Prioritätsinversion. Thread 0 wird durch „mutex 0“ angehalten, der sich im Besitz von „thread 1“ mit niedrigerer Priorität befindet. Ein Fehler könnte hier entstehen, wenn der Entwickler nicht über das Risiko dieser Prioritätsinversion Bescheid wüsste. Es ist sogar eher anzunehmen, dass es sich hier um einen typischen Fall dafür handelt, dass Threads unterschiedlicher Priorität um ein und dieselbe, durch „mutex 0“ abgesicherte Ressource konkurrieren.
Bild 4 illustriert eine komplexe Prioritätsinversion mit Vererbung der Mutex-Priorität. Aufgedeckt wird diese Situation durch Anklicken des „TR“-Icons (Thread Resume) in der mit „Thread 0“ bezeichneten Zeitachse. Unter „Selected Event“ wird hier das gleiche Prioritätsinversions-Problem dargestellt wie im vorigen Beispiel, jedoch ist der Mutex, der die Ressource reserviert, hier für Prioritätsinversion eingestellt. Wenn also „Thread 0“ versucht, in den Besitz des Mutex zu gelangen, erbt „Thread 1“ zeitweilig die Priorität von „Thread 0“. Die Folge ist, dass „Thread 2“ – obwohl er während des Prioritätsinversions-Fensters für die Verarbeitung bereit wurde (sichtbar im System Timer Thread im Icon „TR“) – nicht verarbeitet wird, bis die Prioritätsinversion behoben und die Verarbeitung von „Thread 0“ beendet ist.
- Neuer Debugger für die Systemanalyse
- Neuer Debugger für die Systemanalyse
- Verbesserung der Applikations-Performance
- Behebung von Prioritätsinversions-Problemen
- Neuer Debugger für die Systemanalyse
