Startseite > Automotive > Software + Tools > Load Balancing in AUTOSAR-Multicore-Systemen (Teil 2)

AUTOSAR

Load Balancing in AUTOSAR-Multicore-Systemen (Teil 2)

27. April 2010, 11:50 Uhr | Von Dr. Kathrin D. Scheidemann, Michael Knapp und Claus Stellwag

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 4

Verteilung von Runnable-Gruppen

Eine Möglichkeit, die Nachteile der freien Verteilung von Runnables zu umgehen, besteht darin, Runnables die ursprünglich im gleichen Task abgearbeitet wurden und zwischen denen Datenfluss besteht, zu Gruppen zusammenzufassen und dann die Verteilung dieser Gruppen zu optimieren. Bild 3 visualisiert diese Vorgehensweise, wobei links die Runnables aus Bild 2 dargestellt sind, die zu Gruppen zusammengefasst wurden, wenn sie auf den gleichen Task abgebildet waren und zwischen ihnen Datenfluss besteht. Auf der rechten Seite ist die Aufteilung der Runnable-Gruppen auf die Rechenkerne dargestellt. Dabei sind die Optimierungsziele bei der Verteilung von Runnable-Gruppen die gleichen wie bei der freien Verteilung von Runnables: Ausgeglichene Laufzeit der Runnables in den Partitionen und möglichst wenig Intercore-Kommunikation. Für das hier abgebildete einfache Beispiel ergibt sich dasselbe Verteilungsszenario wie in Bild 2. Bei der Optimierung der Verteilung bestehen aber durch die Gruppenbildung weniger Freiheitsgrade, wodurch sich im Allgemeinen ungünstigere Verteilungsszenarien ergeben. Die Ausführungsreihenfolge von Runnables eines ursprünglichen Tasks ist aber auf diese Weise, wenn notwendig, ohne zusätzliche Synchronisation deterministisch.

Mit Hilfe dieser Verteilungsstrategie ließ sich ein definierter Datenfluss zwischen Runnables eines ursprünglichen Tasks – zwischen denen es in der ursprünglichen Architektur zu Datenfluss kam – erreichen. Es kann jedoch immer noch zu "Lost Updates" kommen, wenn auf unterschiedlichen Rechenkernen Runnables unterschiedlicher Priorität Sender derselben Datenobjekte sind. Dies lässt sich verhindern, indem Runnable-Gruppen, die Sender gleicher Daten sind, vor der Optimierung vereinigt, also gemeinsam verteilt werden. Mit dieser Verteilungsstrategie ergab sich für die hier untersuchte Motorsteuerung eine Schnittstelle zwischen den beiden Software- Komponenten mit insgesamt 20 Sender-Empfänger-Ports. Rechenkern 1 konnte um 13 % entlastet werden. Die Auslastung von Rechenkern 2 betrug 56 % der Auslastung von Rechenkern 1, und die "Workload" war insgesamt 29 % größer als bei nicht parallelisierter Software. Die Verteilung der "Workload" auf beide Rechenkerne ist also wesentlich unausgeglichener als bei einer freien Verteilung von Runnables, was aus den reduzierten Freiheitsgraden bei der Optimierung resultiert. Jedoch ist der Overhead durch Intercore-Kommunikation größer. Im Gegensatz zur freien Verteilung von Runnables bietet diese Strategie aber den Vorteil, dass die Ausführungsreihenfolge von Runnables eines ursprünglichen Tasks, zwischen denen Datenfluss stattfindet, deterministisch ist.