AUTOSAR
Load Balancing in AUTOSAR-Multicore-Systemen (Teil 2)
Fortsetzung des Artikels von Teil 3
"Lost Updates"
Gibt es bei Sender-Empfänger- Kommunikation mehrere Sender des gleichen Datums, kann es zu "Lost Updates" kommen. Nachrichten eines Runnables gehen verloren, wenn sie geschickt werden, während ein anderes Runnable auf einem anderen Rechenkern auf seiner lokalen Kopie des alten Wertes arbeitet, bevor es wiederum selbst einen aktualisierten Wert schickt. In der ursprünglichen Software war sichergestellt, dass Daten, die von verschiedenen Runnables eines Tasks gelesen werden, sich während des Ablaufs des Tasks nur ändern können, wenn Sie von höher priorisierten Tasks geschrieben werden. Diese Annahme gilt im Verteilungsszenario nicht mehr, da jetzt niedrig priorisierte Tasks gleichzeitig mit höher priorisierten Tasks aktiv sein können. Dies wurde im vorliegenden Kontext von Entwicklern jedoch als unkritisch eingeschätzt, da die Verteilung von Runnables auf Tasks in der Entwicklung erst relativ spät festgelegt wird und deswegen keine Annahmen über Datenkonsistenz dieser Art getroffen werden.
Bei entsprechender Optimierung der Verteilung von ausführbaren Einheiten der hier untersuchten Motorsteuerung ergab sich eine Schnittstelle zwischen den beiden resultierenden Software-Komponenten mit insgesamt 29 Sender-Empfänger-Ports. So ließ sich Rechenkern 1 gegenüber der Ausführung der kompletten Software auf einem Rechenkern um 31 % entlasten. Die "Workload" insgesamt stieg um 22 %, was sich einerseits mit dem etwas gestiegenen Aufwand durch die Funktion der Laufzeitumgebung erklären lässt, andererseits aber auch stark davon geprägt ist, dass Zugriffe auf das gemeinsame RAM im eingesetzten Dual-Prozessor-Board-Aufbau wesentlich langsamer sind als Zugriffe auf das kernlokale RAM. Zur Sicherstellung von Datenkonsistenz werden von der Laufzeitumgebung "Spinlocks" verwendet, die im aktuellen Aufbau ebenfalls unrealistisch langsam sind. Auf tatsächlicher Multicore-Hardware ist daher weniger Overhead zu erwarten. Die Auslastung von Rechenkern 2 betrug 77 % der Auslastung von Rechenkern 1.
Die erste diskutierte Verteilungsstrategie schnitt – verglichen mit den im Weiteren vorgestellten Strategien – bei der Performanzanalyse relativ gut ab. Allerdings hat die Strategie den eklatanten Nachteil, dass Garantien, die durch die ursprüngliche Architektur gegeben waren, wie beispielsweise der definierte Datenflusses zwischen Runnables eines Tasks, im parallelisierten Fall nicht mehr gelten. Wenn nicht ausgeschlossen werden kann, dass dies zu ungewolltem Systemverhalten führt, ist diese Verteilungsstrategie nicht anwendbar.
Jobangebote+ passend zum Thema
- Load Balancing in AUTOSAR-Multicore-Systemen (Teil 2)
- Aufbau
- Freie Verteilung von Runnables
- "Lost Updates"
- Verteilung von Runnable-Gruppen
- Parallelisierung in einer Barrier-Architektur
- Eingesetzte Heuristik
- Auswertung und Ausblick
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Bedienung/HMI
Near Field Communication zur Interaktion mit dem Fahrzeug
Entwicklung
Produktionsfreigabe von AUTOSAR-Basis-Software
Steuergeräte-Software
Serienerprobter und OSEK/VDX-kompatibler Kommuminkations-Stack
Sicherheit
Erstes adaptives Kurvenlicht für Motorräder vorgestellt
SPS in der Fahrzeugtechnik
Automation trifft Automotive
AUTOSAR
Auf dem Weg zum globalen Standard
Prozess-Management/Software-Entwicklung
AUTOSAR: Method Park und Mecel kooperieren
AUTOSAR
Software-Plattform entspricht HIS-Empfehlung
Entwicklung von Kfz-Software
Wechsel von OSEK zu AUTOSAR
AUTOSAR
Load Balancing in AUTOSAR-Multicore-Systemen (Teil 1)
