Startseite > Embedded > Entwicklungstools > Echtzeit für Multicore

Virtualisierung

Echtzeit für Multicore

15. Juli 2011, 11:57 Uhr | Von Christophe Grujon und Andreas Knape

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Echtzeit für Multicore

Inter-Prozess-Kommunikation

Heutige Multicore-Prozessorarchitekturen mit gemeinsamen Speicher- und I/O-Bereichen erscheinen auf den ersten Blick am besten geeignet für SMP-Implementierungen. Bei genauerer Prüfung, wie oben zuvor diskutiert, arbeiten Echtzeitapplikationen besser in einer AMP-Umgebung, bei der Applikationsprozesse auf festgelegten Prozessorkernen mit dediziertem I/O laufen. Um das zu erreichen, können zwei Techniken angewendet werden: Embedded-Virtualization und »Global Objects« mit einem darauf abgestimmtem Kommunikationsnetzwerk.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Bild 3 zeigt eine Multicore-CPU mit partitioniertem Speicher und zugehörigem, dediziertem I/O. Applikation 1 ist verteilt auf CPU 1 und 2 - wie im SMP-Fall. CPU 3 und 4 sind geladen mit App. 2, 3 und 4 - ebenfalls wie im SMP-Fall. Der Unterschied besteht aber darin, dass I/Os ebenfalls spezifischen Applikationen zugeordnet sind. Zu beachten ist, dass I/Os auch Teilen einer Applikation zugeordnet sein können. Zum Beispiel können die Interrupts, die von App. 1a bearbeitet werden, nicht die Ausführung der App. 1b beeinträchtigen.

Unter Embedded-Virtualization versteht man die Partitionierung eines Systems in dedizierte Prozessumgebungen, die durch das Segmentieren des gemeinsamen Speichers und der I/Os entstehen und auf diesen einzelnen Segmenten ein Betriebsystem pro Prozessorkern etablieren. Das entspricht somit einer AMP-Umgebung. Applikationen werden auf dedizierten CPU-Kernen geladen, was sicherstellt, dass ausreichende Rechenkapazität zur Verfügung steht, um auf die wechselnden Anforderungen externer Events reagieren zu können.

Durch Reservieren spezifischer Rechenkapazitäten kann das System zeitgerecht auf Ereignisse reagieren und eine deterministische Ausführung sicherstellen. I/Os werden somit von einer dedizierten CPU bearbeitet, die entsprechend dafür vorgesehen wurde. Das hat den erwünschten Effekt, dass Applikationen, die auf anderen Kernen laufen, nicht unnötigerweise unterbrochen werden. Die zweite Technologie, die beim AMP zum Einsatz kommt, ist das Global-Object-Networking (siehe Kasten »Was ist GOBSnet?«). Das ist ein Systemdienst, der die Mittel für Software-Objekte zur Verfügung stellt, um zwischen Prozessorkernen und Speicherpartitionen kommunizieren zu können.

Somit können Applikationen miteinander interagieren, die auf mehrere Kerne und separierten Speicher aufgeteilt wurden, als würden sie auf einem Prozessor laufen. Der Einsatz globaler Objekte in Embedded Systemen ist recht einfach: Objekte, auf die von mehreren, externen Prozessen zugegriffen werden soll, müssen als »global« deklariert werden. Somit sind diese einfach zu implementieren, und es bedarf keines weiteren Anpassens vorhandenen Codes.

Ein »Global Objects«-Netzwerk stellt eine gemanagte Umgebung mit integrierter Initialisierung und Detektierungsdiensten zur Verfügung, sodass eine Applikation dynamisch zur Ladezeit auf eine weitere oder auch mehrere CPUs verteilt werden kann. Prozesse, die Dienste anderer Prozesse benötigen, werden automatisch gefunden, und deren Ausführungsort erfasst ein lokaler Dienst, um jederzeit eine Referenz auf die etablierten IPC-Links sicherzustellen. Dieser Dienst signalisiert einem initiierenden Prozess auch, ob der Zielprozess und/oder die Kommunikationsverbindungen gestört sind.

Zusätzlich setzt der lokale Dienst alle Aufzeichnungen nicht mehr existierender Objekte und Links zurück, wenn der aufrufende Prozess diese nicht mehr benötigt. Da das Global-Objects-Netzwerk in das Betriebssystem integriert wurde, ist dessen Overhead gering. Es ist nicht erforderlich, dass der Applikationsentwickler dazu weitere, spezifische Software entwickeln muss. Der Dienst verhält sich deterministisch und ist deutlich effizienter als traditionelle IPC-Schnittstellen.

Über die Autoren:

Chris Grujon ist Product Manager, Andreas Knape ist Field Marketing Representative, beide bei TenAsys.

Was ist »GOBSnet«?
Im Jahr 2009 stellte TenAsys das Echtzeitbetriebssystem »INtime for Windows 4.0« vor. Diese Version ermöglicht es, Echtzeitapplikationen auf Multicore-Prozessoren zu verteilen und diese weiterhin auch parallel zu Windows zu betreiben. Dazu benutzt diese Version von INtime ein »Global Objects«-Netzwerk namens »GOBSnet«. Applikationen können über mehrere INtime-Instanzen verteilt werden und trotzdem direkt miteinander kommunizieren. Das GOBSnet ermöglciht eine solche Kommunikation von Echtzeitprozessen, selbst wenn diese auf unterschiedlichen Instanzen des Echtzeitbetriebssystems laufen. Die Funktion ist sehr ähnlich zur Kommunikation mit Windows durch das »INtime NTX«-Protokoll, allerdings berücksichtigt es dabei Echtzeit-Thread-Prioritäten und mehrfachen Client-Zugriff. Die neue Funktion von GOBSnet erlaubt es einem Echtzeitprozess, Objekte zu referenzieren, die unter einer anderen INtime-Kernel-Instanz existieren. GOBSnet besteht aus zwei Basiskomponenten: dem GOBS-Manager und dem Distributed-System-Manager (DSM). Diese Komponenten haben unabhängige Funktionen. Der GOBS-Manager verwaltet die Relationen der Global-Objects untereinander und der DSM überwacht die Relationen zwischen verschiedenen Prozessen. Zur Referenzierung werden Knoten eines Netzwerks von Prozessorsystemen mit logischen Namen versehen, die dann dem Knoten und der Plattform entsprechen. Zum Beispiel: Objekte auf Host 1, Node A werden auch unter diesem Namen angesprochen. Wenn ein Prozess einem anderen Daten schicken will, ermittelt es den Ort des entfernten Prozesses und speichert die Daten in ein Referenzobjekt, das vom GOBS-Manager gehalten und verwaltet wird. Von diesem Zeitpunkt an benutzt der Prozess diese Referenz, um dann über Mailboxes, Speicherobjekte oder Semaphoren zu kommunizieren. Die gleiche Funktion eignet sich auch für die Kommunikation über global definierte Speicherblöcke und Semaphoren. Alle diese Mechanismen sind in das Betriebssystem integriert und auf dessen Echtzeitstruktur hin abgestimmt, um die deterministische Kommunikation zwischen den Knoten sicherzustellen. Im März 2011 stellte TenAsys das »INtime distributed RTOS« vor. Dabei handelt es sich um eine autonome 32-Bit-Echtzeitbetriebssystemsplattform, welche die Ressourcen eines Multicore-Prozessorsystems durch Embedded-Virtualization-Methoden paritioniert und somit über mehrere INtime-Instanzen verfügt. Applikationen können trotzdem über mehrere Kerne verteilt werden, sehr ähnlich zu einem SMP-System.

Was ist »GOBSnet«?

Im Jahr 2009 stellte TenAsys das Echtzeitbetriebssystem »INtime for Windows 4.0« vor. Diese Version ermöglicht es, Echtzeitapplikationen auf Multicore-Prozessoren zu verteilen und diese weiterhin auch parallel zu Windows zu betreiben. Dazu benutzt diese Version von INtime ein »Global Objects«-Netzwerk namens »GOBSnet«. Applikationen können über mehrere INtime-Instanzen verteilt werden und trotzdem direkt miteinander kommunizieren. Das GOBSnet ermöglciht eine solche Kommunikation von Echtzeitprozessen, selbst wenn diese auf unterschiedlichen Instanzen des Echtzeitbetriebssystems laufen. Die Funktion ist sehr ähnlich zur Kommunikation mit Windows durch das »INtime NTX«-Protokoll, allerdings berücksichtigt es dabei Echtzeit-Thread-Prioritäten und mehrfachen Client-Zugriff. Die neue Funktion von GOBSnet erlaubt es einem Echtzeitprozess, Objekte zu referenzieren, die unter einer anderen INtime-Kernel-Instanz existieren. GOBSnet besteht aus zwei Basiskomponenten: dem GOBS-Manager und dem Distributed-System-Manager (DSM). Diese Komponenten haben unabhängige Funktionen. Der GOBS-Manager verwaltet die Relationen der Global-Objects untereinander und der DSM überwacht die Relationen zwischen verschiedenen Prozessen. Zur Referenzierung werden Knoten eines Netzwerks von Prozessorsystemen mit logischen Namen versehen, die dann dem Knoten und der Plattform entsprechen. Zum Beispiel: Objekte auf Host 1, Node A werden auch unter diesem Namen angesprochen. Wenn ein Prozess einem anderen Daten schicken will, ermittelt es den Ort des entfernten Prozesses und speichert die Daten in ein Referenzobjekt, das vom GOBS-Manager gehalten und verwaltet wird. Von diesem Zeitpunkt an benutzt der Prozess diese Referenz, um dann über Mailboxes, Speicherobjekte oder Semaphoren zu kommunizieren. Die gleiche Funktion eignet sich auch für die Kommunikation über global definierte Speicherblöcke und Semaphoren. Alle diese Mechanismen sind in das Betriebssystem integriert und auf dessen Echtzeitstruktur hin abgestimmt, um die deterministische Kommunikation zwischen den Knoten sicherzustellen. Im März 2011 stellte TenAsys das »INtime distributed RTOS« vor. Dabei handelt es sich um eine autonome 32-Bit-Echtzeitbetriebssystemsplattform, welche die Ressourcen eines Multicore-Prozessorsystems durch Embedded-Virtualization-Methoden paritioniert und somit über mehrere INtime-Instanzen verfügt. Applikationen können trotzdem über mehrere Kerne verteilt werden, sehr ähnlich zu einem SMP-System.