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 6

Eingesetzte Heuristik

In den durchgeführten Untersuchungen wurde zur Verteilung eine Heuristik eingesetzt, die eine Liste von Runnables verwaltet, welche verteilbar sind. Diese werden auf die später parallel ausgeführten Tasks verteilt. Runnables sind verteilbar, wenn alle Runnables, die (im nicht parallelen Fall) vor ihnen ausgeführt wurden und die Daten schreiben, die sie lesen, entweder bereits dem gleichen Rechenkern oder vor dem letzten Synchronisationspunkt einem anderen Rechenkern zugeteilt wurden.

Sind alle verteilbaren Runnables verteilt – spätestens aber, wenn die Summe der Laufzeiten seit dem letzten Synchronisationspunkt die maximale Laufzeit des rechenintensivsten Runnables im Task überschreitet –, lässt sich ein Synchronisationspunkt einfügen. Wird diese Heuristik auf die hier untersuchte Motorsteuerung angewendet, lässt sich Rechenkern 1 theoretisch (unter der Annahme, dass die Synchronisation an sich keine Zeit kostet) um 18 % entlasten. Die erreichbare, theoretische Entlastung lässt sich durch den Einsatz von anderen Optimierungsmethoden als der beschriebenen Heuristik unter Umständen wesentlich verbessern. Die Auslastung beider Rechenkerne ist bei dieser Strategie immer gleich. Für "Barriers" wird in AUTOSAR bisher keine standardisierte API angeboten. Sie lassen sich aber als "Complex Device Driver" unter Rückgriff auf die angebotenen "Spinlocks" realisieren.

Die tatsächlich gemessene Auslastung von Rechenkern 1 war in diesem Szenario allerdings sogar höher als die Auslastung im nicht parallelisierten Fall. Dies lässt sich dadurch erklären, dass Synchronisation auf der aktuellen Hardware in der aktuellen Implementierung sehr langsam ist. Wird die Synchronisation versuchsweise entfernt, lässt sich eine Entlastung erreichen, die mit der Entlastung bei einer freien Verteilung von Runnables vergleichbar ist. Die Schnittstelle umfasst dabei 485 Sender- Empfänger-Ports. Anzumerken ist, dass die in diesem Verteilungsszenario eingesetzte Implementierung der Laufzeitumgebung den Zugriff auf Datenobjekte nicht durch "Spinlocks" schützt, da der exklusive Zugriff auf diese bereits durch die Synchronisation sichergestellt ist. Ist die Synchronisation (wie im hier beschriebenen Aufbau) sehr zeitaufwendig, kann es sinnvoll sein, weniger Synchronisationspunkte zuzulassen und stattdessen weniger ausgeglichene Laufzeiten in einander entsprechenden Tasks in Kauf zu nehmen. Beispielsweise in einer Formulierung des Optimierungsproblems als "Mixed Integer Problem" [7] ist es möglich, die zur Synchronisation minimal notwendige Zeit zu berücksichtigen, so dass diese gleich bei der Optimierung des "Deployments" einbezogen wird.

Die Parallelisierung von Software in einer Barrier-Architektur bietet die Möglichkeit, einen hohen Grad an Parallelität zu erreichen. Je nachdem, wie viel Parallelität die Software-Architektur zulässt und wie variabel die Laufzeiten der Runnables in unterschiedlichen Betriebssituationen sind, besteht allerdings die Gefahr, dass durch Optimierung – im Hinblick auf den "Worst Case" – im Normalfall viel Rechenzeit durch aktives Warten an "Barriers" verschwendet wird. Das ließe sich verhindern, wenn, anstatt „Barriers“ zu verwenden, an Synchronisationspunkten jeweils lauffähig werdende Task-Stücke auf allen Rechenkernen aktiviert würden. Eine Task-Aktivierung kann jedoch wiederum an sich wesentlich zeitaufwendiger sein, als die mit "Barriers" verbundenen Operationen.