DE102021130092A1

DE102021130092A1 - System zur parallelen verarbeitung von anwendungsalgorithmen für middleware-knoten unter verwendung von threads

Info

Publication number: DE102021130092A1
Application number: DE102021130092.4A
Authority: DE
Inventors: Shige Wang; Wei Tong; Shuqing Zeng
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2021-01-12
Filing date: 2021-11-18
Publication date: 2022-07-14
Also published as: CN114764375A; US20220222129A1

Abstract

Ein System umfasst eine Warteschlange, einen Speicher und einen Controller. Die Warteschlange ist so konfiguriert, dass sie eine Nachricht zwischen einem ersten Thread und einem zweiten Thread überträgt, wobei der erste Thread und der zweite Thread als Teil eines einzelnen Prozesses implementiert sind und wobei eine der Nachricht entsprechende Datenmenge kleiner als eine festgelegte Datenmenge ist. Der Speicher ist für die gemeinsame Nutzung von Daten zwischen dem ersten Thread und dem zweiten Thread konfiguriert, wobei die zwischen dem ersten Thread und dem zweiten Thread gemeinsam genutzte Datenmenge größer ist als die festgelegte Datenmenge. Der Controller ist so konfiguriert, dass er den einzelnen Prozess ausführt, der die gleichzeitige Ausführung (i) eines ersten Middleware-Knoten-Prozesses als ersten Thread und (ii) eines zweiten Middleware-Knoten-Prozesses als zweiten Thread umfasst.

Description

EINLEITUNG
Die Informationen in diesem Abschnitt dienen dazu, den Kontext der Offenbarung allgemein darzustellen. Arbeiten der vorliegend genannten Erfinder, soweit sie in diesem Abschnitt beschrieben sind, sowie Aspekte der Beschreibung, die zum Zeitpunkt der Anmeldung möglicherweise nicht zum Stand der Technik gehören, sind weder ausdrücklich noch stillschweigend als Stand der Technik gegen die vorliegende Offenbarung zugelassen.
Die vorliegende Offenbarung bezieht sich auf die Verarbeitung bei Middleware-Knoten.
Ein Fahrzeug kann mit zahlreichen Sensoren ausgestattet sein, z.B. Kameras, Infrarotsensoren, Radarsensoren, Lidarsensoren usw. Ein Middleware-Framework kann zum Sammeln, Verarbeiten und Analysieren der von den Sensoren erfassten Daten verwendet werden. Auf der Grundlage der Ergebnisse der Analyse können dann verschiedene Maßnahmen durchgeführt werden. Das Middleware-Framework kann mehrere Controller umfassen, die entsprechende Prozesse implementieren, wobei jeder Prozess ein Unterprogramm innerhalb einer Anwendung sein kann. Jeder Prozess kann auf einem dedizierten Controller implementiert werden, wobei jeder Controller einen oder mehrere Kerne (oder zentrale Verarbeitungseinheiten) umfasst. Ein Controller kann auch als Multi-Core-Prozessor bezeichnet werden.
Zum Beispiel kann eine Kamera Bilder aufnehmen. Ein erster Controller kann einen Erfassungsprozess durchführen, der den Empfang und die Koordinierung der Verarbeitung der Bilder umfasst, um Objekte in den Bildern zu erfassen und zu identifizieren. Ein zweiter Controller kann einen Segmentierungsprozess durchführen und die Ergebnisse der vom ersten Controller durchgeführten Verarbeitung empfangen und die weitere Verarbeitung koordinieren, um die Positionen der identifizierten Objekte relativ zum Fahrzeug zu bestimmen. Jeder der Controller kann dieselbe Grafikverarbeitungseinheit (GPU) anweisen, bestimmte Berechnungen für jeden der jeweiligen Prozesse durchzuführen. Die von der GPU durchgeführte Verarbeitung ist zeitlich gemultiplext und erfolgt sequentiell. Das Zeitmultiplexen der Berechnungen für die jeweiligen Prozesse ist mit Verzögerungen verbunden und führt zu einer unzureichenden Auslastung der GPU-Ressourcen.
ZUSAMMENFASSUNG
Ein System wird bereitgestellt und umfasst eine Warteschlange, einen Speicher und einen Controller. Die Warteschlange ist so konfiguriert, dass sie eine Nachricht zwischen einem ersten Thread und einem zweiten Thread überträgt, wobei der erste Thread und der zweite Thread als Teil eines einzelnen Prozesses implementiert sind und wobei die der Nachricht entsprechende Datenmenge kleiner als eine festgelegte Datenmenge ist. Der Speicher ist für die gemeinsame Nutzung von Daten durch den ersten Thread und den zweiten Thread konfiguriert, wobei die durch den ersten Thread und durch den zweiten Thread gemeinsam genutzte Datenmenge größer ist als die festgelegte Datenmenge. Der Controller ist so konfiguriert, dass er den einzelnen Prozess ausführt, der die gleichzeitige Ausführung (i) eines ersten Middleware-Knoten-Prozesses als ersten Thread und (ii) eines zweiten Middleware-Knoten-Prozesses als zweiten Thread umfasst.
In anderen Merkmalen teilen sich der erste Thread und der zweite Thread den gleichen Bereich eines Hauptspeicheradressraums des Speichers für Thread-Code, Thread-Daten, Grafikverarbeitungsmodul-Code und Grafikverarbeitungsmodul-Daten.
In anderen Merkmalen enthält das System außerdem ein Grafikverarbeitungsmodul, das ein Ausführungsmodul umfasst, das so konfiguriert ist, dass es den Code für den ersten Thread gleichzeitig mit dem Code für den zweiten Thread ausführt.
In anderen Merkmalen enthält das System ferner ein Grafikverarbeitungsmodul, das ein Kopiermodul umfasst, das so konfiguriert ist, dass es Grafikverarbeitungsmodul-Daten für den ersten Thread gleichzeitig mit Grafikverarbeitungsmodul-Daten für den zweiten Thread kopiert.
In weiteren Merkmalen umfasst das System ferner: einen Speicher für ein Grafikverarbeitungsmodul; und ein Grafikverarbeitungsmodul, das so konfiguriert ist, dass es gleichzeitig Daten für den ersten Thread und den zweiten Thread zwischen einem Hauptspeicheradressraum des Speichers und dem Speicher des Grafikverarbeitungsmoduls überträgt.
In anderen Merkmalen umfasst das System ferner ein Grafikverarbeitungsmodul. Der erste Thread erzeugt erste Berechnungen für einen ersten Algorithmus des ersten Middleware-Knotens. Der zweite Thread erzeugt zweite Berechnungen für einen zweiten Algorithmus des zweiten Middleware-Knotens. Das Grafikverarbeitungsmodul führt gleichzeitig die ersten Berechnungen für einen zweiten Frame aus, während es die zweiten Berechnungen für einen ersten Frame ausführt, wobei der zweite Frame nach dem ersten Frame erfasst und empfangen wird.
In anderen Merkmalen werden der erste und der zweite Thread als Teil eines einzelnen Middleware-Knotens implementiert.
In anderen Merkmalen ist der Controller konfiguriert, um: einen Hauptspeicheradressraum des Speichers, der von dem ersten Thread und dem zweiten Thread gemeinsam genutzt werden soll, zuzuweisen und festzulegen; und die Warteschlange festzulegen, die vom ersten und zweiten Thread verwendet werden soll.
Bei anderen Merkmalen ist der Hauptspeicheradressraum für Lese- und Schreiboperationen dediziert. Die Warteschlange ist für Sende- und Empfangsoperationen dediziert.
In anderen Merkmalen ist der Controller konfiguriert, um: festzustellen, ob die Verwendung der Warteschlange angemessen ist, und gegebenenfalls eine Verbindung mit der Warteschlange herzustellen, falls sie zugewiesen ist, und die Warteschlange zuzuweisen, wenn sie nicht zugewiesen war; und festzustellen, ob die Verwendung eines gemeinsam genutzten Bereichs des Speichers angemessen ist, und gegebenenfalls auf den gemeinsam genutzten Bereich zuzugreifen, wenn er zugewiesen ist, und den gemeinsam genutzten Bereich zuzuweisen, wenn er nicht zugewiesen war.
In anderen Merkmalen wird ein Verfahren bereitgestellt, das umfasst: Zuweisen einer Warteschlange für die Übertragung einer Nachricht zwischen einem ersten Thread und einem zweiten Thread, wobei der erste Thread und der zweite Thread als Teil eines einzelnen Prozesses implementiert sind und wobei die der Nachricht entsprechende Datenmenge kleiner ist als eine festgelegte Datenmenge; Zuweisen eines Speichers zur gemeinsamen Nutzung von Daten zwischen dem ersten Thread und dem zweiten Thread, wobei die zwischen dem ersten Thread und dem zweiten Thread gemeinsam genutzte Datenmenge größer ist als die festgelegte Datenmenge; und Ausführen des einzelnen Prozesses, der das gleichzeitige Ausführen (i) eines ersten Middleware-Knoten-Prozesses als ersten Thread und (ii) eines zweiten Middleware-Knoten-Prozesses als zweiten Thread umfasst.
In anderen Merkmalen teilen sich der erste Thread und der zweite Thread den gleichen Bereich eines Hauptspeicheradressraums des Speichers für Thread-Code, Thread-Daten, Grafikverarbeitungsmodul-Code und Grafikverarbeitungsmodul-Daten.
In anderen Merkmalen umfasst das Verfahren ferner die Ausführung von Code über ein Grafikverarbeitungsmodul und für den ersten Thread gleichzeitig mit Code für den zweiten Thread.
In anderen Merkmalen umfasst das Verfahren ferner das Kopieren von Grafikverarbeitungsmodul-Daten über ein Grafikverarbeitungsmodul und für den ersten Thread gleichzeitig mit Grafikverarbeitungsmodul-Daten für den zweiten Thread.
In anderen Merkmalen umfasst das Verfahren ferner die gleichzeitige Übertragung von Daten für den ersten Thread und den zweiten Thread zwischen einem Hauptspeicheradressraum des Speichers und einem Grafikverarbeitungsmodulspeicher.
In anderen Merkmalen umfasst das Verfahren außerdem: Erzeugen erster Berechnungen über den ersten Thread für einen ersten Algorithmus des ersten Middleware-Knotens; und Erzeugen zweiter Berechnungen über den zweiten Thread für einen zweiten Algorithmus des zweiten Middleware-Knotens; und gleichzeitiges Ausführen der ersten Berechnungen für einen zweiten Frame über ein Grafikverarbeitungsmodul, während die zweiten Berechnungen für einen ersten Frame ausgeführt werden, wobei der zweite Frame nach dem ersten Frame erfasst und empfangen wird.
In anderen Merkmalen werden der erste und der zweite Thread als Teil eines einzelnen Middleware-Knotens implementiert.
In anderen Merkmalen umfasst das Verfahren außerdem: Zuweisen und Festlegen eines Hauptspeicheradressraums des Speichers, der von dem ersten Thread und dem zweiten Thread gemeinsam genutzt werden soll; und Festlegen der Warteschlange, die vom ersten Thread und zweiten Thread verwendet werden soll.
Bei anderen Merkmalen ist der Hauptspeicheradressraum für Lese- und Schreiboperationen dediziert. Die Warteschlange ist für Sende- und Empfangsoperationen dediziert.
In anderen Merkmalen umfasst das Verfahren außerdem: Feststellen, ob die Verwendung der Warteschlange angemessen ist, und gegebenenfalls Verbinden mit der Warteschlange, falls sie zugewiesen ist, und Zuweisen der Warteschlange, falls sie nicht zugewiesen war; und Festlegen, ob die Verwendung eines gemeinsam genutzten Bereichs des Speichers angemessen ist, und gegebenenfalls Zugreifen auf den gemeinsam genutzten Bereich, falls dieser zugewiesen ist, und Zuweisen des gemeinsam genutzten Bereichs, falls dieser nicht zugewiesen war.
Weitere Anwendungsbereiche der vorliegenden Offenbarung ergeben sich aus der detaillierten Beschreibung, den Ansprüchen und den Zeichnungen. Die ausführliche Beschreibung und die spezifischen Beispiele dienen lediglich der Veranschaulichung und sollen den Umfang der vorliegenden Offenbarung nicht einschränken.
Figurenliste
Die vorliegende Offenbarung wird aus der detaillierten Beschreibung und den beigefügten Zeichnungen vollständiger ersichtlich, wobei gilt:

1A ist ein funktionales Blockschaltbild eines beispielhaften Middleware-Frameworks, das Middleware-Knoten als Prozesse implementiert;
1B ist ein Zeitdiagramm, das die Abfolge von Verarbeitungsereignissen darstellt, die von den zentralen Verarbeitungseinheiten (CPUs) und der GPU des Middleware-Frameworks von 1 durchgeführt werden;
2 ist ein funktionales Blockschaltbild, das die Speichernutzung und die GPU-Verarbeitung für die von den Middleware-Knoten von 1A durchgeführten Prozesse darstellt;
3 ist ein funktionales Blockschaltbild eines Fahrzeugs mit einem Middleware-Framework, das gemäß der vorliegenden Offenbarung Middleware-Knoten und entsprechende Algorithmen als Threads eines einzelnen Prozesses implementiert;
4 ist ein funktionales Blockschaltbild eines beispielhaften Middleware-Knotens mit Threads und Zugriff auf eine Warteschlange und einen gemeinsamen Hauptspeicher gemäß der vorliegenden Offenbarung;
5 ein funktionales Blockschaltbild, das die gemeinsame Speichernutzung von Threads und die parallele GPU-Verarbeitung für die Threads darstellt, wie sie von dem Middleware-Knoten von 4 gemäß der vorliegenden Offenbarung durchgeführt wird;
6 stellt die Zuordnung von Kommunikationsunterschieden zwischen prozessbasierten Nachrichtenübertragungen und Thread-basierten Nachrichtenübertragungen kleiner Datenmengen gemäß der vorliegenden Offenlegung dar;
7 stellt die Zuordnung von Kommunikationsunterschieden zwischen prozessbasierten Nachrichtenübertragungen und Thread-basierten Nachrichtenübertragungen großer Datenmengen gemäß der vorliegenden Offenlegung dar;
8 stellt die Unterschiede zwischen prozessbasierter Zuordnung und Thread-basierter Zuordnung von geplanten Parametern gemäß der vorliegenden Offenbarung dar;
9 zeigt ein Zuordnungsverfahren zur Festlegung einer Warteschlange und eines gemeinsamen Hauptspeicherraums gemäß der vorliegenden Offenbarung; und
10 zeigt ein Verfahren zur Thread-Initialisierung gemäß der vorliegenden Offenbarung.

In den Zeichnungen können Bezugszahlen erneut verwendet werden, um ähnliche und/oder identische Elemente zu bezeichnen.
DETAILLIERTE BESCHREIBUNG
Middleware-Knoten, die als Prozesse ausgeführt werden, zwingen eine GPU dazu, von verschiedenen Middleware-Knoten aus zu arbeiten, indem sie Zeitmultiplexing verwenden, um Berechnungen zu planen, die für jeden der Knoten ausgeführt werden sollen. Eine GPU kann Hunderte von Kernen umfassen. Das Zeitmultiplexen der Berechnungen ist nicht nur zeitaufwändig, sondern führt auch zu einer unzureichenden Auslastung der GPU-Ressourcen, da zu jedem Zeitpunkt nur ein kleiner Prozentsatz der GPU-Kerne für die entsprechenden Berechnungen verwendet wird. Die Implementierung der Middleware-Knoten als Prozesse unter Verwendung von Zeitmultiplexing führt zu einem geringen Durchsatz der Algorithmen, einer unzureichenden Auslastung der Hardware und langen Verarbeitungsverzögerungen bzw. -dauern.
1A zeigt ein Beispiel für ein Middleware-Framework 100, das Middleware-Knoten 102, 104 als Prozesse implementiert, die über eine erste CPU 106, eine zweite CPU 108 und eine GPU 110 ausgeführt werden. Obwohl als CPUs 106, 108 dargestellt, können die CPUs 106, 108 durch entsprechende Controller ersetzt werden. Die CPUs 106, 108 können in einem Fahrzeug implementiert sein, oder eine der CPUs kann im Fahrzeug implementiert und die andere der CPUs an einem entfernten Ort außerhalb des Fahrzeugs implementiert sein. Das gilt auch für die Controller. Im Folgenden werden die Begriffe CPU und GPU auch als zentrale Verarbeitungsmodule bzw. Grafikverarbeitungsmodule bezeichnet.
Im gezeigten Beispiel erzeugt ein Sensor 112 (z.B. eine Kamera) ein Ausgangssignal mit Daten (z.B. ein aufgenommenes Bild), die an den ersten Knoten 102 geliefert werden. Der erste Knoten 102 kann über die erste CPU 106 und die GPU 110 implementiert werden. Der zweite Knoten 104 kann durch die zweite CPU 108 und die GPU 110 implementiert werden. Die erste CPU 106 koordiniert die für den ersten Prozess (oder den ersten Algorithmus 107) auszuführenden Operationen. Die zweite CPU 108 koordiniert die für den zweiten Prozess (oder zweiten Algorithmus 109) auszuführenden Operationen. Die CPUs 106, 108 weisen die GPU 110 an, bestimmte Berechnungen für die jeweiligen Prozesse durchzuführen. Die CPUs 106, 108 können entsprechende neuronale Netze (z.B. neuronale Faltungsnetze) implementieren.
1B zeigt ein Zeitdiagramm, das die Abfolge der von den CPUs 106, 108 und der GPU 110 des Middleware-Frameworks durchgeführten Verarbeitungsoperationen darstellt. Im gezeigten Beispiel empfängt die erste CPU 106
ein erstes Bild und führt während der Implementierung des ersten Knotens N1 einen ersten Code c1 aus und weist die GPU 110 an, Berechnungen (oder Operationen) g11, g12 durchzuführen. Die erste CPU 106 empfängt dann die Ergebnisse der von der GPU 110 durchgeführten Berechnungen und führt einen zweiten Code c2 aus. Die Berechnungen können als Kernels bezeichnet werden, die der Grafikprozessor 110 durchführt und entsprechende Ausgabedaten erzeugt. Dieser Prozess wird durch die Kästen 120, 122 und 124 dargestellt. Dies kann z.B. Informationen über erkannte Objekte liefern. Die erste CPU 106 liefert das erste Bild und die erkannten Objektinformationen an die zweite CPU 108. Die erste CPU 106 wiederholt diesen Vorgang dann für ein nächstes (oder zweites) Bild (dargestellt durch die Kästen 126, 128, 130).
Die zweite CPU 108 empfängt das erste Bild und die Ergebnisse der Ausführung des zweiten Codes c2 und führt den ersten Code c1 für den zweiten Knoten N2 aus, der sich von dem Code c1 für den ersten Knoten N1 unterscheidet. Die zweite CPU 108 weist dann die GPU an, Berechnungen (oder Operationen) g21 durchzuführen. Die zweite CPU 108 empfängt dann die Ergebnisse der von der GPU 110 durchgeführten Berechnungen und führt den zweiten Code c2 aus. Dieser Vorgang wird durch die Kästen 132, 134 und 136 dargestellt. Der Prozess der zweiten CPU 108 kann aus Gründen der Segmentierung und/oder z.B. zum Abgleich von Bild-, Objekt- und/oder anderen Sensordaten durchgeführt werden, um den Standort eines Objekts zu bestimmen. Die GPU 110 kann eine Rückmeldung an die zweite CPU 108 geben, und die zweite CPU 108 bestimmt dann die Koordinaten des Objekts. Die GPU kann ein Array bzw. Feld von Daten an die erste CPU 106 und die zweite CPU 108 liefern. Die CPUs 106, 108 können das Objekt identifizieren und bestimmen, wo sich das Objekt befindet, sowie die mit der Identifizierung und dem ermittelten Ort verbundenen Konfidenz-Stufen. Die zweite CPU 108 kann Objekte z.B. als Kästchen in einem Bild anzeigen. Beispiele für einige der von den CPUs 106, 108 durchgeführten Operationen sind Ziehen, vollständiges Verbinden bzw. full connect und Faltungsoperationen.
2 zeigt ein Diagramm, das die Speichernutzung und die GPU-Verarbeitung für die Prozesse darstellt, die von den Middleware-Knoten 102 (N1), 104 (N2) von 1 ausgeführt werden. Der erste Knoten N1 kann einen ersten Prozess eines Betriebssystems nach einem ersten Algorithmus implementieren. Der zweite Knoten N2 kann einen zweiten Prozess eines Betriebssystems nach einem zweiten Algorithmus implementieren. Jeder Prozess verwendet einen dedizierten Bereich des Hauptspeicheradressraums. Zwei Bereiche 200, 202 werden als Teil eines Hauptspeicheradressraums 203 dargestellt und sind voneinander getrennt. Die Prozesse teilen sich nicht denselben Speicherbereich und verfügen über dedizierte, getrennt liegende Speicherbereiche für Code und Daten.
Wenn ein Prozess erstellt wird, wird eine Tabelle verwendet, um den verfügbaren Speicherplatz im Hauptspeicher für den Prozess anzugeben. Die Tabelle gibt an, welcher Speicher für den Prozess verwendet werden kann, während dieser ausgeführt wird. Jedem Prozess wird ein anderer Speicherbereich zugewiesen, von dem aus auf den verfügbaren Speicher zugegriffen und dieser genutzt werden kann.
Wie gezeigt, enthält der erste Bereich 200 einen ersten Code N1:c1 für den ersten Knoten, einen zweiten Code N1:c2 für den ersten Knoten, Daten für den ersten Knoten N1, Berechnungen g11, g12 für die GPU 110 und erste GPU-Daten g1, die Ergebnisse der Berechnungen g11, g12 enthalten können. Der zweite Bereich 202 enthält einen ersten Code N2:c1 für den zweiten Knoten, einen zweiten Code N2:c2 für den zweiten Knoten, Daten des zweiten Knotens N2, Berechnungen g21 für die GPU 110 und zweite GPU-Daten g2, die Ergebnisse der Berechnungen g21 enthalten können. Der GPU-Code (oder die Berechnungen) g12, g11, g21 von verschiedenen Knoten wird zur Ausführung durch eine Ausführungs-Engine (oder Ausführungsmodul) 210 eines GPU-Treibers 212 der GPU 110 vorgelegt und zeitlich gemultiplext und somit einzeln ausgeführt. Für den GPU-Code und die GPU-Daten kann dedizierter Speicherplatz bereitgestellt werden, der nicht gemeinsam genutzt wird. Die Daten für die GPU-Berechnungen werden auch sequentiell (nacheinander) in den GPU-Speicher 214 kopiert. Eine Kopier-Engine (oder Kopiermodul) 216 des GPU-Treibers 212 kopiert die GPU-Daten sequentiell in und aus den Bereichen 200, 202 und dem GPU-Speicher 214. Die genannten Operationen erzwingen implizit die serielle Ausführung der Knoten N1, N2 (als versteckte Serialisierung bezeichnet). Der GPU-Treiber 212 lässt nicht zu, dass zwei separate Prozesse gleichzeitig ausgeführt werden, sondern erzwingt die Serialisierung von Code und Daten, die sich auf N1 und N2 beziehen. Die CPUs 106, 108 und die GPU110 können für jedes empfangene Bild die gleichen Operationen durchführen (oder wiederholen).
Die hier dargelegten Beispiele umfassen ein Thread-basiertes Middleware-Framework, das Middleware-Knoten als Threads als Teil eines einzelnen Prozesses für einen resultierenden einzelnen Middleware-Knoten implementiert. Dies ermöglicht einen höheren Grad an Parallelität für die Verarbeitung bei der Implementierung von Middleware-Knoten (z.B. Robotik-Betriebssystem (ROS)-Knoten oder anderen Middleware-Knoten). Ein ROS-Knoten ist eine Art Middleware-Knoten, der für ein System zum autonomen Fahren verwendet werden kann. Jeder der Middleware-Knoten kann in einem oder mehreren Prozessoren (oder Kernen) eines einzelnen Controllers implementiert sein.
Der hier verwendete Begriff „Programm“ kann sich auf einen im Speicher abgelegten Code beziehen, der von einem Controller ausgeführt wird, um eine oder mehrere Aufgaben zu erfüllen. Ein Programm kann Teil eines Betriebssystems oder vom Betriebssystem getrennt sein. Die Programme können als Anwendungen bezeichnet werden. Das Programm benötigt Speicher und verschiedene Betriebssystem-Ressourcen, um zu laufen. Ein „Prozess“ bezieht sich auf ein Programm, das in den Speicher geladen wurde, zusammen mit allen Ressourcen, die das Programm zum Betrieb benötigt. Wenn ein Prozess startet, werden ihm Speicher und Ressourcen zugewiesen.
Der hier verwendete Begriff „Thread“ ist eine Ausführungseinheit innerhalb eines Prozesses. Ein Prozess kann einen oder mehrere Threads umfassen. Die Threads eines Prozesses teilen sich Speicher und Ressourcen. Die Threads können in sich überschneidenden Zeiträumen und/oder gleichzeitig ausgeführt werden. Die Threads eines Middleware-Knotens, wie er in 4 dargestellt ist, können nicht von separaten Controllern (oder Multi-Core-Prozessoren) implementiert werden. Dies steht im Gegensatz zu Prozessen, die von separaten Controllern (oder Multi-Core-Prozessoren) implementiert werden können. Wenn ein erster Thread erstellt wird, wird dem ersten Thread ein Speichersegment zugewiesen, das für einen entsprechenden Prozess vorgesehen ist. Dadurch kann ein anderer erstellter Thread denselben zugewiesenen Speicherbereich mit dem ersten Thread teilen. Threads eines Prozesses haben ähnliche Adressen, die sich auf Segmente desselben Speicherbereichs beziehen. Die Größe des gemeinsamen Speicherbereichs kann dynamisch sein und sich ändern, wenn zusätzlicher Speicher benötigt wird und/oder zusätzliche Threads für den Prozess erstellt werden.
Die vorgestellten Beispiele umfassen ein Multi-Thread-Laufzeitsystem und ein Verfahren zur Konfiguration eines prozessbasierten Knotensystems zu einem System, das die gleichzeitige Ausführung mehrerer Threads zur Implementierung von Middleware-Knoten-Algorithmen ermöglicht. Das System verfügt über eine Middleware-Architektur mit einem Multi-Thread-Modell für einen Middleware-Knoten. Es werden Architektur-Mechanismen für die Thread-Kommunikation und die parallele Ausführung von GPU-Anfragen mithilfe von Warteschlangen und gemeinsam genutztem Speicher abhängig von den ausgetauschten Daten bereitgestellt. Es wird ein Verfahren zur Umwandlung eines prozessbasierten Middleware-Knotens in einen Multi-Thread-Middleware-Knoten bereitgestellt.
3 zeigt ein Fahrzeug 300 mit einem Middleware-Framework (oder Middleware-System) 302, das so konfiguriert ist, dass es Middleware-Knoten und entsprechende Algorithmen als jeweilige Threads implementiert. Das Fahrzeug 300 kann ein teilweise oder vollständig autonomes Fahrzeug oder ein anderes Fahrzeug sein. Ein Beispiel für einen Middleware-Knoten ist in 4 dargestellt. Das Middleware-Framework 302 kann einen oder mehrere Controller (dargestellt ist ein Controller 303) und Sensoren 306 umfassen. Die Controller implementieren einen Middleware-Dienst, der Open-Source-Software und die Ausführung von Middleware-Knoten umfassen kann. Der Middleware-Dienst und das entsprechende System sorgen für Transparenz zwischen Anwendungen und Hardware. Das Middleware-System ist kein Betriebssystem und erleichtert die Implementierung von Anwendungen. Das Middleware-System ermöglicht eine transparente Kommunikation zwischen den Anwendungen. Das bedeutet, dass sich die Anwendungen überall befinden können, z.B. in einem Computer, einem Fahrzeugspeicher, einer Edge-Cloud-Computing-Vorrichtung, einer Cloud-basierten Netzwerkvorrichtung oder anderswo. Die Anwendungen können auf demselben Kern oder auf verschiedenen Kernen laufen. Wenn eine Anwendung den Middleware-Dienst aufruft, um eine zweite Anwendung zu erreichen, wird ein Signal erzeugt und vom Middleware-Dienst an die zweite Anwendung weitergeleitet.
Jeder der Controller kann ein entsprechendes neuronales Netz implementieren und einen oder mehrere Prozessoren (oder Kerne) enthalten. In einer Ausführungsform implementieren die Controller entsprechende neuronale Faltungsnetzwerke. Jeder Middleware-Knoten kann auf einem oder mehreren Kernen (oder CPUs) eines ausgewählten Controllers implementiert werden. Jeder Middleware-Knoten kann auf nicht mehr als einem der Controller implementiert werden. Zusätzlich zur Implementierung von Middleware-Knoten als Threads und als Teil eines einzelnen Prozesses können der eine oder die mehreren Controller auch Middleware-Knoten als separate Prozesse implementieren, wie oben in Bezug auf 1A-2 beschrieben.
Jeder der Controller kann CPUs (oder zentrale Verarbeitungsmodule) 307, eine GPU 304 und einen Hauptspeicher 305 umfassen. Die GPU 304 kann Kerne 308 und einen Vorrichtungsspeicher 309 umfassen. Die CPUs 307, die GPU 304 und der Hauptspeicher 305 können über eine Schnittstelle (oder einen Bus) 311 miteinander kommunizieren. Die Sensoren 306 können sich im gesamten Fahrzeug 300 befinden und Kameras 310, Infrarot (IR)-Sensoren 312, Radarsensoren 314, Lidarsensoren 316 und/oder andere Sensoren 318 sein. Die Controller und Sensoren 306 können direkt miteinander kommunizieren, über einen CAN (controller area network)-Bus 320 und/oder über einen Ethernet-Switch 322 miteinander kommunizieren. Im gezeigten Beispiel sind die Sensoren 306 über den Ethernet-Switch 322 mit den Controllern verbunden, können aber auch direkt mit den Controllern 202 und/oder dem CAN-Bus 320 verbunden sein. Im Hauptspeicher 305 können z.B. Code 325 und Daten 326 gespeichert werden. Die Daten 326 können die hier erwähnten Parameter und andere Daten enthalten. Der Code 325 kann die hier erwähnten Algorithmen enthalten.
Das Fahrzeug 300 kann ferner ein Fahrgestell-Steuermodul 330, Drehmomentquellen wie einen oder mehrere Elektromotoren 332 und eine oder mehrere Maschinen (eine Maschine 334 ist dargestellt) umfassen. Das Fahrgestell-Steuermodul 330 kann die Verteilung des Ausgangsdrehmoments auf die Achsen des Fahrzeugs 300 über die Drehmomentquellen steuern. Das Fahrgestell-Steuermodul 330 kann den Betrieb eines Antriebssystems 336 steuern, das den/die Elektromotoren) 332 und die Maschine(n) 334 umfasst. Die Maschine 334 kann einen Anlasser 350, ein Kraftstoffsystem 352, ein Zündsystem 354 und ein Drosselklappensystem 356 umfassen.
Das Fahrzeug 300 kann außerdem ein Karosseriesteuermodul (BCM) 360, ein Telematikmodul 362, ein Bremssystem 363, ein Navigationssystem 364, ein Infotainmentsystem 366, eine Klimaanlage 370, andere Aktoren 372, andere Vorrichtungen 374 und andere Fahrzeugsysteme und -module 376 umfassen. Zu den anderen Aktoren 372 ma gehören Lenkaktoren und/oder andere Aktoren. Die Controller, Systeme und Module 303, 330, 360, 362, 364, 366, 370, 376 können über den CAN-Bus 320 miteinander kommunizieren. Eine Stromquelle 380 kann enthalten sein und das BCM 360 und andere Systeme, Module, Controller, Speicher, Vorrichtungen und/oder Komponenten mit Strom versorgen. Die Stromquelle 380 kann eine oder mehrere Batterien und/oder andere Stromquellen umfassen. Die Controller 303 und/oder das BCM 360 können abhängig von erkannten Objekten, Standorten der erkannten Objekte und/oder anderen zugehörigen Parametern Gegenmaßnahmen und/oder autonome Operationen durchführen. Dies kann die Steuerung der genannten Drehmomentquellen und Aktoren sowie die Bereitstellung von Bildern, Hinweisen und/oder Anweisungen über das Infotainmentsystem 366 umfassen.
Das Telematikmodul 362 kann Transceiver 382 und ein Telematik-Steuermodul 384 enthalten, die für die Kommunikation mit anderen Fahrzeugen, Netzwerken, Edge-Computing-Vorrichtungen und/oder Cloud-basierten Vorrichtungen verwendet werden können. Das BCM 360 kann die Module und Systeme 362, 363, 364, 366, 370, 376 und andere Aktoren, Vorrichtungen und Systeme (z.B. die Aktoren 372 und die Vorrichtungen 374) steuern. Diese Steuerung kann auf den Daten der Sensoren 306 basieren.
4 zeigt ein Beispiel für einen Middleware-Knoten 400, bei dem es sich um eine Funktion handeln kann, die Anforderungen bzw. Anfragen und Antwortobjekte empfängt. Es können mehrere Middleware-Knoten implementiert werden, die miteinander kommunizieren können. Die Middleware-Knoten können Programme, Anwendungen und/oder Programme sein, die als Teil einer Anwendung laufen. Der Middleware-Knoten 400 kann Threads 402, 404 enthalten und auf eine Warteschlange 406 und einen gemeinsamen Hauptspeicher 408 zugreifen. Obwohl der Middleware-Knoten 400 mit zwei Threads dargestellt ist, kann der Middleware-Knoten 400 einen oder mehrere Threads umfassen. Jeder der Threads 402, 404 kann einen entsprechenden Algorithmus oder einen Teil eines einzelnen Algorithmus implementieren.
So kann beispielsweise der erste Thread 402 einen Erfassungsalgorithmus und der zweite Thread 404 einen Segmentierungs- und/oder Objektausrichtungsalgorithmus durchführen. Wie dargestellt, implementiert der erste Thread 402 einen ersten Algorithmus 410 und der zweite Thread 404 einen zweiten Algorithmus 412. Die Threads 410, 412 können Zugriff auf jeweilige lokale Speicher 414, 416 haben. Die Warteschlange 406 kann sich auf einen Teil des Hauptspeichers 305 von 3, einen entfernten Speicher oder eine Kombination davon beziehen. Der gemeinsam genutzte Hauptspeicher 408 bezieht sich auf einen Teil (oder zugewiesenen Adressbereich) des Hauptspeichers 305, der von jedem der Threads 410, 412 (oder einem oder mehreren Kernen, die die Threads implementieren) gemeinsam genutzt wird und auf den diese zugreifen können. Die Threads 402, 404 sind als Teil ein und desselben Prozesses implementiert, obwohl die Operationen in der Regel als zwei oder mehr separate Prozesse implementiert worden sein können. Da die Threads als Teil ein und desselben Prozesses implementiert sind, können sie sich denselben Hauptspeicherbereich teilen. Dadurch können der Code und die Daten, die mit den Threads verknüpft sind (als Thread-Code und Thread-Daten bezeichnet), und eine GPU nahe beieinander im Hauptspeicher untergebracht werden, wie in 5 gezeigt. Da sie Teil desselben Prozesses sind, können die Berechnungen für die Threads gleichzeitig von der GPU implementiert werden.
Die Threads des Middleware-Knotens 400 werden statisch definiert, wenn der Middleware-Knoten 400 definiert wird. Die von den Threads gemeinsam genutzten Daten werden in einem Middleware-Knotenraum für den Zugriffsschutz definiert. Für die Datenkommunikation können eine oder mehrere Warteschlangen verwendet werden, die jeweils den von den Middleware-Knoten implementierten Algorithmen entsprechen können. Alle Threads, gemeinsam genutzten Datenvariablen und Warteschlangen können konfiguriert werden, wenn der Middleware-Knoten 400 initialisiert wird.
Jeder der Threads kann mit Eigenschaften definiert werden, die eine parallele Ausführung unterstützen. Jeder der Threads kann Programmanweisungen enthalten, z.B. eine commQList, eine sharedMList, eine gpuStreamList, ein schedParam, eine init()-Funktion, eine run()-Funktion und/oder andere Programmanweisungen. Die commQList wird zur Verbindung mit den Warteschlangen für die Übertragung kleiner Datenmengen (z.B. Objekterfassungs- und/oder Identifizierungsdaten) zwischen Threads und/oder Speicherbereichen verwendet. Die sharedMList dient zur Verbindung mit dem gemeinsamen Hauptspeicher 408 für die Übertragung großer Datenmengen (z.B. zu einem Bild gehörende Daten).
Die gpuStreamList wird verwendet, um eine Verbindung zu Kanälen für GPU-Berechnungen herzustellen. Der schedParam kann Parameter für die Planung enthalten, wenn ein Ressourcenkonflikt zwischen zwei oder mehreren Threads besteht. Der schedParam kann verwendet werden, wenn eine Arbitrierung bzw. Entscheidung durchgeführt wird, um zu bestimmen, welcher Thread ausgeführt werden soll. Threads können gleichzeitig ausgeführt werden, und wenn es eine begrenzte Ressource gibt, kann der schedParam verwendet werden, um zu bestimmen und/oder zu identifizieren, welcher Thread die Ressource zuerst nutzen kann. Die Funktion init() ist eine Initialisierungsfunktion, die zur Initialisierung von Warteschlangen, gemeinsamem Speicher, der Programmanweisung gpuStreamList und der Programmanweisung schedParam für die Threads verwendet wird. Die Funktion run() ist eine Funktion, die für die normale Ausführung eines Algorithmus implementiert wird. Die Funktionen init() und run() können verwendet werden, um einen Middleware-Knoten für einen Prozess in einen Thread umzuwandeln.
Der Middleware-Knoten 400 ermöglicht die parallele Verarbeitung von Threads, wodurch größere Datenmengen verarbeitet werden können. Zum Beispiel die Verarbeitung von 10 Frames pro Sekunde aus Acht-Megabyte-Bildern anstelle von 10 Frames pro Sekunde aus Ein-Megabyte-Bildern. Eine GPU kann Hunderte von Kernen enthalten (z.B. 256 Kerne), und in der Regel wird nur ein Teil der Kerne von einem einzelnen Middleware-Knoten gleichzeitig verwendet. Die GPU würde in der Regel die Algorithmusberechnungen für einen ersten Middleware-Knoten ausführen, bevor sie die Algorithmusberechnungen für einen zweiten Middleware-Knoten ausführt. Die GPU war in der Regel nicht in der Lage, Bildinformationen für zwei Middleware-Knoten gleichzeitig zu verarbeiten. Als weiteres Beispiel können aufgrund der sequentiellen Zeitmultiplex-Implementierung der Berechnungen nur 20 % der Kerne einer GPU zur Ausführung eines Algorithmus für einen Middleware-Knoten verwendet werden, während die anderen 80 % der Kerne im Leerlauf sind. Die hier beschriebene parallele GPU-Verarbeitung von Thread-Berechnungen ermöglicht eine höhere prozentuale Auslastung der GPU-Kerne zu einem bestimmten Zeitpunkt.
5 zeigt ein Diagramm, das die gemeinsame Speichernutzung von Threads und die parallele GPU-Verarbeitung für die Threads 402, 404 darstellt, wie sie durch den Middleware-Knoten 400 von 4 durchgeführt wird. Die Threads 402, 404 implementieren die Algorithmen A1, A2, die mit den Algorithmen 107, 109 von 1A identisch oder ähnlich sein können. Die Threads 402, 404 teilen sich einen gemeinsamen Speicherbereich 406 des gemeinsamen Hauptspeichers 408. Der Speicherbereich 406 enthält: den mit dem ersten Algorithmus verknüpften ersten und zweiten Code A1 :c1, A1 :c2; den mit dem zweiten Algorithmus verknüpften ersten und zweiten Code A2:c1, A2:c2; die A1-Daten für die ersten Algorithmus-Daten; die GPU-Berechnungen g11, g12; die ersten GPU-Daten g1; die A2-Daten für die zweiten Algorithmus-Daten; die GPU-Berechnungen g21; und die zweiten GPU-Daten g2. Die Codes für die verschiedenen Threads werden gleichzeitig in denselben Adressraumbereich 406 des gemeinsamen Hauptspeichers 408 kopiert. Die Daten für die Threads werden auch gleichzeitig in den Adressraumbereich 406 des gemeinsamen Hauptspeichers 408 kopiert. Jeder Thread hat einen oder mehrere dedizierte Streams bzw. Datenströme für GPU-Operationen. Operationen aus demselben Stream werden in eine Warteschlange (oder einen First-infirst-out (FIFO)-Speicher) eingespeist. Operationen aus verschiedenen Streams werden gleichzeitig (oder parallel) ausgeführt, wenn genügend Ressourcen vorhanden sind. So können beispielsweise die GPU-Codes g12, g11 für den ersten Algorithmus einer Ausführungs-Engine (oder -Modul) 420 des GPU-Treibers 422 geliefert werden, während der GPU-Code g21 für den zweiten Algorithmus an die Ausführungs-Engine 420 geliefert wird. Die Ausführungs-Engine 420 kann die GPU-Berechnungen g12, g11, g21 gleichzeitig ausführen und die daraus resultierenden GPU-Daten (g1-Daten und g2-Daten) im GPU-Speicher 430 speichern. Die GPU-Berechnungen g12, g11 und/oder g21 können im GPU-Speicher 430 gespeichert werden. Eine Kopier-Engine (oder -Modul) 424 des GPU-Treibers 422 kann gleichzeitig die GPU-Daten g1 und g2 aus dem GPU-Speicher 430 in den Speicherbereich 406 kopieren. Die gestrichelte Linie 440 trennt die CPU-Verarbeitung auf der linken Seite der Linie 440 von der parallelen GPU-Verarbeitung auf der rechten Seite der Linie 440.
6 zeigt die Zuordnung bzw. das Mapping von Kommunikationsunterschieden zwischen prozessbasierten Nachrichtenübertragungen und Thread-basierten Nachrichtenübertragungen. Die Nachrichtenübertragungen erfolgen zwischen Middleware-Knoten und zwischen Middleware-Threads und dienen der Übertragung kleiner Datenmengen (weniger als eine vorgegebene Datenmenge).
Für die Kommunikation zwischen Middleware-Knoten werden Nachrichtenwarteschlangen verwendet. Eine Datenstruktur definiert die auszutauschenden Informationen. Für die Transparenz wird ein Veröffentlichung-Anmeldung- bzw. Publish-Subscribe-Mechanismus verwendet. Die Middleware-Knoten N1 und N2 (oder 600, 602) und die Threads T1 und T2 (604, 606) sind zusammen mit den Nachrichtenwarteschlangen 608, 610 dargestellt. Die Nachrichten-Warteschlangen 608, 610 können Teile des Hauptspeichers eines Fahrzeugs oder an anderer Stelle sein. Die Warteschlangen 608, 610 können sich im bordseitigen Speicher des Fahrzeugs oder an einem entfernten Standort befinden. Die Warteschlangen 608, 610 können als FIFO-Speicherbereiche implementiert werden, die für kleine Datenübertragungen geeignet sind.
Der Middleware-Knoten N1 kann dem anderen Middleware-Knoten N2 anzeigen, dass N1 plant, eine Nachricht zu senden, was als Veröffentlichung der Nachricht bezeichnet wird. Dazu kann das Senden einer Anzeige an die Nachrichtenwarteschlange 608 gehören. Der zweite Knoten N2 kann dann die Nachricht quittieren und einen Rückruf auslösen. Der zweite Knoten N2 meldet sich bei der Nachrichtenwarteschlange an, um die Nachricht zu empfangen, kann ein Blockwarten durchführen, um die Nachricht zu empfangen, und kann auf die Nachrichtenwarteschlange zugreifen, um die Nachricht zu empfangen.
Die Kommunikation zwischen den Threads T1 und T2 für kleine Datenübertragungen umfasst die Verwendung von Nachrichtenwarteschlangen. Die Veröffentlichungsfunktion entspricht einem Sendevorgang in einer Thread-basierten Umgebung. Die Anmeldefunktion entspricht einem Empfangsvorgang in der Thread-basierten Umgebung. Das Mapping bzw. die Zuordnung wird zum Zeitpunkt des Designs bzw. Entwurfs durchgeführt. Thread T1 kann die Nachricht erstellen, zuordnen und an die Nachrichtenwarteschlange 610 senden. Der Thread T1 kann dann die Nachricht durch Zugriff auf die Nachrichtenwarteschlange 610 empfangen. Der Thread T2 kann dann die Nachricht empfangen und später vernichten. Jeder Thread kann Nachrichten erstellen, zuordnen und/oder zerstören.
7 zeigt die Zuordnung bzw. das Mapping von Kommunikationsunterschieden zwischen prozessbasierten Nachrichtenübertragungen und Thread-basierten Nachrichtenübertragungen von großen Datenmengen (z.B. Bilddaten). Die Nachrichtenübertragung erfolgt zwischen Middleware-Knoten und zwischen Middleware-Threads.
Wie in 6 dargestellt, werden für die Kommunikation zwischen den Middleware-Knoten Nachrichtenwarteschlangen verwendet. Eine Datenstruktur definiert die auszutauschenden Informationen. Für die Transparenz wird ein Veröffentlichung-Anmeldung- bzw. Publish-Subscribe-Mechanismus verwendet. In 7 sind die Middleware-Knoten N1 und N2 (oder 600, 602) und die Threads T1 und T2 (604, 606) zusammen mit der Nachrichtenwarteschlange 608 und einem gemeinsamen Hauptspeicher 700 dargestellt. Der Middleware-Knoten N1 kann dem anderen Middleware-Knoten N2 anzeigen, dass N1 plant, eine Nachricht zu senden, was als Veröffentlichung der Nachricht bezeichnet wird. Dazu kann das Senden einer Anzeige an die Nachrichtenwarteschlange 608 gehören. Der zweite Knoten N2 kann dann die Nachricht quittieren und einen Rückruf auslösen. Der zweite Knoten N2 meldet sich bei der Nachrichtenwarteschlange an, um die Nachricht zu empfangen, kann ein Blockwarten durchführen, um die Nachricht zu empfangen, und kann auf die Nachrichtenwarteschlange zugreifen, um die Nachricht zu empfangen. So werden die Daten zwischen den Middleware-Knoten N1 und N2 unabhängig von der Datenmenge über die Nachrichtenwarteschlange 608 auf die gleiche Weise übertragen.
Die Kommunikation zwischen den Threads T1 und T2 bei großen Datenübertragungen unterscheidet sich von der Kommunikation zwischen den Threads T1 und T2 bei kleinen Datenübertragungen. Für große Datenübertragungen verwenden die Threads anstelle einer Warteschlange den gemeinsamen Hauptspeicher 700, der sich an Bord eines entsprechenden Fahrzeugs befindet. Warteschlangen sind wegen der damit verbundenen Verzögerungszeit für kleine Datenübertragungen geeignet, aber nicht für große Datenübertragungen. Warteschlangen eignen sich für kleine Hin- und Herübertragungen von Daten, führen aber zu erheblichen Verzögerungen, wenn sie für die Übertragung großer Datenmengen verwendet werden.
Außerdem wird durch die Verwendung eines gemeinsamen Speichers das duplizierte Kopieren von Daten vermieden, was Verzögerungen und den Stromverbrauch minimiert. Bei der Übertragung von kleinen Datenmengen mit Warteschlangen: müssen die Daten aus einem lokalen Speicher eines ersten Middleware-Knotens übertragen werden; muss der entsprechende Zeiger bzw. Pointer der Daten „abgeflacht“ („flattened“ oder umgewandelt) werden, bevor er in die Warteschlange gestellt wird; werden die Daten und der abgeflachte Zeiger in die Warteschlange übertragen; werden die Daten und der abgeflachte Zeiger von der Warteschlange an einen zweiten Middleware-Knoten übertragen; wird die Abflachung des Zeigers in ein Format für den zweiten Middleware-Knoten rückgängig gemacht („deflattened“); und werden die Daten in einem anderen lokalen Speicher des zweiten Middleware-Knotens gespeichert. Die Abflachung des Zeigers kann sich auf die Wiederherstellung des Zeigers in eine ursprüngliche Struktur und/oder ein ursprüngliches Format beziehen. Beispiele für den lokalen Speicher sind in 4 dargestellt.
Im Gegensatz dazu ist bei der Verwendung eines gemeinsamen Hauptspeichers die große Datenmenge für jeden der Threads T1 und T2 zugänglich, und es muss kein Zeiger für die Verwendung durch die Threads abgeflacht (oder konvertiert) werden. Die Daten werden ein einziges Mal im gemeinsamen Hauptspeicher abgelegt und sind dann für jeden der Threads T1 und T2 zugänglich. So können beispielsweise beide Threads ein Erfassungsbild aus dem gemeinsamen Hauptspeicher aufrufen. Jeder Thread, der eine Duplikat-Nachricht für gespeicherte Daten erzeugt, wird darüber informiert, dass dieselbe Nachricht bereits schon erstellt wurde und die Daten bereits im gemeinsamen Hauptspeicher gespeichert sind. Wenn die Threads T1 und T2 beide die Funktion „Shared Memory Create“ bzw. „Gemeinsamen Speicher erstellen“ für denselben gemeinsamen Speicherbereich aufrufen, darf der eine Thread den gemeinsamen Speicherbereich erstellen, und der andere Thread empfängt einen Zeiger für den gemeinsamen Speicherbereich. Die Arbitrierung bzw. Entscheidung für diesen Prozess kann von einem Kern durchgeführt werden, der einen oder mehrere der Threads T1 und T2 implementiert.
Für die Threads T1 und T2 wird jede erzeugte Nachricht auf den gemeinsamen Hauptspeicher 700 abgebildet bzw. zugeordnet, der die gleiche Datenstruktur aufweist. Die Veröffentlichungsfunktion wird in der Thread-basierten Umgebung auf einen geschützten Schreibvorgang abgebildet. Die Anmeldefunktion wird in der Thread-basierten Umgebung auf einen geschützten Lesevorgang geschützten abgebildet. Es kann eine Synchronisierung ohne Warten und Sperren verwendet werden. Alle Mappings bzw. bzw. die Zuordnungen werden zum Zeitpunkt des Designs bzw. Entwurfs durchgeführt.
8 zeigt die Unterschiede zwischen der prozessbasierten Zuordnung und der Thread-basierten Zuordnung der geplanten Parameter. Ein Middleware-Knoten wird mit Hilfe von Parametern für die Prozessplanung eingeplant. Dazu gehören die Einstellung der Triggerrate, die Prozessoraffinität, die Prioritätsstufe (oder NICE-Stufe) und die Zeitplanungsrichtlinien. Standardmäßig werden Middleware-Knoten mit einer Ring- bzw. Round-Robin (RR)-Richtlinie geplant. Als Beispiel ist ein Middleware-Knoten N (800) gezeigt, der aufweist: eine Triggerrate (oder eine voreingestellte Middleware-Rate); eine Callback(sub) (oder Rückruf-Anmeldefunktion); eine Affinität, eingestellt bei cpu.set; eine Prioritätsstufe zwischen 0-255; und FIFO-, RR- und NICE-Richtlinien. Der Middleware-Knoten N hat: einen entsprechenden Treiber N-Driver 802 für ein neuronales Netz, der mit 10 Hz arbeitet, cpu0 verwendet, eine Prioritätsstufe von 10 hat und eine FIFO-Veröffentlichungsfunktion FIFO pub(k) verwendet; und einen Knoten Multinetz 804, der abhängig von der Ausgabe des N-Driver 802 und einer Callback(Daten)-Funktion unter Verwendung von cpu1 gemäß einer Prioritätsstufe von 8 und einer FIFO-Richtlinie startet.
Der Thread eines Middleware-Knotens erbt die Parameter des ursprünglichen Middleware-Knotens. Die Richtlinien gelten für einen einzelnen Knoten. Die Richtlinien der Threads in einem Knoten können mit Hilfe eines Parameters auf Knotenebene die Richtlinien der ursprünglichen Knoten beibehalten. Wenn Thread-Richtlinien den Zeitplan des Knotens nicht aufrechterhalten können, kann dieser Thread einen Rückruf an einen Middleware-Knoten vornehmen. Ein Thread T (810) ist gezeigt und hat: einen Trigger-Timer und ein Wait(data) (oder Wartefunktion); eine Affinität, eingestellt bei cpu.set; eine Prioritätsstufe zwischen 0-255; und FIFO-, RR- und NICE-Richtlinien. Der Thread T hat: einen entsprechenden Treiber für ein neuronales Netz T-Driver 812, der mit dem Timer (10 Hz) arbeitet, cpu0 verwendet, eine Prioritätsstufe von 10 hat und Daten gemäß einer FIFO-Richtlinie überträgt; und einen Knoten Multinetz 814, der auf der Grundlage der Ausgabe von T-Driver 812 und Wwait(data)-Funktion unter Verwendung von cpu1 gemäß einer Prioritätsstufe von 8 und einer FIFO-Richtlinie startet.
Die folgenden Verfahren der 9-10 können z.B. durch einen der Controller 303 der 3 implementiert werden. 9 zeigt ein Mapping-bzw. Zuordnungsverfahren zur Erstellung einer Warteschlange und eines gemeinsamen Hauptspeicherraums. Die Operationen des Verfahrens können iterativ durchgeführt werden. Das Verfahren kann bei 900 beginnen. Bei 902 kann der Controller einen Middleware-Knoten-Anwendungsprozess (oder Knoten Ni, wobei i eine Nummer des Knotens ist) finden, der parallel zu einem oder mehreren anderen Middleware-Knoten-Anwendungsprozessen ausgeführt wird.
Bei 904 erstellt der Controller einen Thread Ti für den Knoten Ni. Bei 906 bestimmt der Controller, ob eine GPU 304 verwendet werden soll. Falls ja, wird Operation 908 ausgeführt, andernfalls wird Operation 910 ausgeführt. Bei 908 definiert der Controller einen Stream Si für den Thread Ti.
Bei 910 bestimmt der Controller, ob der Knoten Ni Daten Di veröffentlicht. Falls ja, wird Operation 912 ausgeführt, andernfalls wird Operation 918 ausgeführt. Bei 912 bestimmt der Controller, ob die Datenmenge klein ist (d.h. weniger als eine vorbestimmte und/oder eingestellte Datenmenge) und/oder die Daten von einem bestimmten Typ sind, von dem bekannt ist, dass er eine kleine Datenmenge enthält. Falls ja, wird Operation 914 ausgeführt, andernfalls wird Operation 916 ausgeführt. Bei 914 definiert der Controller einen Warteschlangenraum für den Fall, dass der Thread Ti Sendeoperationen durchführt. Bei 916 definiert der Controller einen gemeinsamen Hauptspeicheradressraum für den Thread Ti, wenn er Schreiboperationen durchführt.
Bei 918 bestimmt der Controller, ob sich der Knoten Ni für die Daten Di angemeldet hat. Falls ja, wird Operation 920 ausgeführt, andernfalls wird Operation 926 ausgeführt. Bei 920 bestimmt der Controller, ob die Datenmenge Di klein ist. Falls ja, wird Operation 922 ausgeführt, andernfalls wird Operation 924 ausgeführt. Bei 922 definiert der Controller einen Warteschlangenplatz für den Thread Ti bei der Durchführung von Empfangsoperationen. Bei 924 definiert der Controller einen gemeinsamen Hauptspeicheradressraum für den Thread Ti bei der Durchführung von Leseoperationen. Bei 926 plant der Controller die Parameter.
Bei 928 bestimmt der Controller, ob es einen weiteren Middleware-Knoten gibt, der parallel zu den zuvor zugeordneten bzw. abgebildeten Middleware-Knoten ausgeführt werden soll. Falls ja, kann die Operation 904 durchgeführt werden, andernfalls kann das Verfahren bei 930 beendet werden.
10 zeigt ein Verfahren zur Initialisierung von Threads. Die Operationen des Verfahrens können iterativ durchgeführt werden. Das Verfahren kann bei 1000 beginnen. Bei 1002 stellt der Controller die geplanten Parameter ein. Bei 1004 bestimmt der Controller, ob es mehrere GPU-Streams gibt. Falls ja, wird Operation 1006 ausgeführt, andernfalls wird Operation 1008 ausgeführt.
Bei 1006 initialisiert der Controller die GPU. Bei 1008 bestimmt der Controller, ob die Kommunikation und/oder die Übertragung von Daten über eine Warteschlange angemessen ist. Falls ja, wird die Operation 1010 durchgeführt, andernfalls kann die Operation 1016 durchgeführt werden.
Bei 1010 stellt der Controller fest, ob bereits eine Kommunikation mit einer Warteschlange besteht (oder zugewiesen wurde). Falls ja, wird Operation 1012 ausgeführt, andernfalls wird Operation 1014 ausgeführt.
Bei 1012 stellt der Controller eine Verbindung zu der vorhandenen zugeordneten Warteschlange her. Bei 1014 erstellt der Controller eine Warteschlange und stellt eine Verbindung zu ihr her. Bei 1016 bestimmt der Controller, ob die Verwendung eines gemeinsam genutzten Hauptspeicheradressraums angemessen ist. Falls ja, wird Operation 1018 ausgeführt, andernfalls wird Operation 1024 ausgeführt.
Bei 1018 stellt der Controller fest, ob bereits ein gemeinsamer Hauptspeicheradressraum zugewiesen wurde. Falls ja, wird Operation 1020 ausgeführt, andernfalls wird Operation 1022 ausgeführt. Bei 1020 stellt der Controller eine Verbindung mit dem bereits zugewiesenen gemeinsamen Hauptspeicherbereich her. Bei 1022 erstellt der Controller einen gemeinsamen Hauptspeicherbereich und stellt eine Verbindung zu diesem her. Im Anschluss an die Operationen 1020, 1022 kann das Verfahren bei 1024 enden.
Die oben genannten Beispiele ermöglichen eine effiziente Nutzung von Hardwareressourcen und verbessern den Durchsatz und die Ressourcennutzung, wodurch die Gesamtsystemkosten minimiert werden.
Die vorstehende Beschreibung ist lediglich erläuternder Natur und soll die Offenbarung, ihre Anwendung oder Verwendung nicht einschränken. Die umfassenden Lehren der Offenbarung können in einer Vielzahl von Formen umgesetzt werden. Obwohl diese Offenbarung bestimmte Beispiele enthält, sollte der wahre Umfang der Offenbarung daher nicht so eingeschränkt werden, da andere Modifikationen bei einem Studium der Zeichnungen, der Beschreibung und der folgenden Ansprüche ersichtlich sind. Es versteht sich, dass ein oder mehrere Schritte innerhalb eines Verfahrens in unterschiedlicher Reihenfolge (oder gleichzeitig) ausgeführt werden können, ohne die Prinzipien der vorliegenden Offenbarung zu verändern. Obwohl jede der Ausführungsformen oben mit bestimmten Merkmalen beschrieben wird, kann jedes einzelne oder mehrere dieser Merkmale, die in Bezug auf eine beliebige Ausführungsform der Offenbarung beschrieben werden, in einer der anderen Ausführungsformen implementiert und/oder mit Merkmalen einer anderen Ausführungsform kombiniert werden, auch wenn diese Kombination nicht explizit beschrieben ist. Mit anderen Worten schließen sich die beschriebenen Ausführungsformen nicht gegenseitig aus, und Permutationen von einer oder mehreren Ausführungsformen miteinander bleiben im Rahmen dieser Offenbarung.
Räumliche und funktionale Beziehungen zwischen Elementen (z.B. zwischen Modulen, Schaltungselementen, Halbleiterschichten usw.) werden mit verschiedenen Begriffen beschrieben, z.B. „verbunden“, „im Eingriff“, „gekoppelt“, „benachbart“, „neben“, „auf“, „über“, „unter“ und „angeordnet.“ Wenn eine Beziehung zwischen einem ersten und einem zweiten Element in der obigen Offenbarung nicht ausdrücklich als „direkt“ beschrieben wird, kann diese Beziehung eine direkte Beziehung sein, bei der keine anderen intervenierenden Elemente zwischen dem ersten und dem zweiten Element vorhanden sind, sie kann aber auch eine indirekte Beziehung sein, bei der ein oder mehrere intervenierende Elemente (entweder räumlich oder funktionell) zwischen dem ersten und dem zweiten Element vorhanden sind. Wie hierin verwendet, sollte die Formulierung „mindestens eines von A, B und C“ als logisches (A ODER B ODER C) unter Verwendung eines nicht-ausschließlichen logischen ODER ausgelegt werden und nicht als „mindestens eines von A, mindestens eines von B und mindestens eines von C“ verstanden werden.
In den Figuren zeigt die Richtung eines Pfeils, wie durch die Pfeilspitze angedeutet, im Allgemeinen den Informationsfluss (z.B. Daten oder Anweisungen) an, der für die Darstellung von Interesse ist. Wenn z.B. Element A und Element B eine Vielzahl von Informationen austauschen, aber die von Element A zu Element B übertragenen Informationen für die Darstellung relevant sind, kann der Pfeil von Element A zu Element B zeigen. Dieser unidirektionale Pfeil impliziert nicht, dass keine weiteren Informationen von Element B zu Element A übertragen werden. Außerdem kann Element B für Informationen, die von Element A an Element B gesendet werden, Anfragen nach oder Empfangsbestätigungen für die Informationen an Element A senden.
In dieser Anmeldung kann, einschließlich der nachfolgenden Definitionen, der Begriff „Modul“ oder der Begriff „Controller“ durch den Begriff „Schaltung“ ersetzt werden. „Der Begriff „Modul“ kann sich auf einen Controller, einen Teil eines Controllers beziehen, Teil eines Controllers sein oder umfassen: einen anwendungsspezifischen integrierten Schaltkreis (ASIC); eine digitale, analoge oder gemischt analog/digitale diskrete Schaltung; eine digitale, analoge oder gemischt analog/digitale integrierte Schaltung; eine kombinatorische Logikschaltung; ein feldprogrammierbares Gate-Array (FPGA); eine Prozessorschaltung (gemeinsam, dediziert oder Gruppe), die Code ausführt; eine Speicherschaltung (gemeinsam, dediziert oder Gruppe), die den von der Prozessorschaltung ausgeführten Code speichert; andere geeignete Hardwarekomponenten, die die beschriebene Funktionalität bereitstellen; oder eine Kombination aus einigen oder allen der oben genannten Möglichkeiten, z.B. in einem System-on-Chip.
Das Modul kann eine oder mehrere Schnittstellenschaltungen enthalten. In einigen Beispielen können die Schnittstellenschaltungen verdrahtete oder drahtlose Schnittstellen umfassen, die mit einem lokalen Netzwerk (LAN), dem Internet, einem Weitverkehrsnetz (WAN) oder Kombinationen davon verbunden sind. Die Funktionalität eines beliebigen Moduls der vorliegenden Offenbarung kann auf mehrere Module verteilt sein, die über Schnittstellenschaltungen verbunden sind. Zum Beispiel können mehrere Module einen Lastausgleich ermöglichen. In einem weiteren Beispiel kann ein Server-Modul (auch als Remote- oder Cloud-Modul bezeichnet) einige Funktionen im Auftrag eines Client-Moduls ausführen.
Der Begriff Code, wie er oben verwendet wird, kann Software, Firmware und/oder Mikrocode umfassen und sich auf Programme, Routinen, Funktionen, Klassen, Datenstrukturen und/oder Objekte beziehen. Der Begriff „Schaltung mit gemeinsam genutztem Prozessor“ (shared processor circuit) umfasst eine einzelne Prozessorschaltung, die einen Teil oder den gesamten Code von mehreren Modulen ausführt. Der Begriff Gruppenprozessorschaltung umfasst eine Prozessorschaltung, die in Kombination mit weiteren Prozessorschaltungen einen Teil oder den gesamten Code von einem oder mehreren Modulen ausführt. Verweise auf Mehrprozessorschaltungen (multiple processor circuits) umfassen mehrere Prozessorschaltungen auf diskreten Chips, mehrere Prozessorschaltungen auf einem einzigen Chip, mehrere Kerne einer einzigen Prozessorschaltung, mehrere Threads einer einzigen Prozessorschaltung oder eine Kombination der oben genannten. Der Begriff „Schaltung mit gemeinsam genutztem Speicher“ (shared memory circuit) umfasst eine einzelne Speicherschaltung, die einen Teil oder den gesamten Code von mehreren Modulen speichert. Der Begriff „Gruppenspeicherschaltung“ umfasst eine Speicherschaltung, die in Kombination mit weiteren Speichern einen Teil oder den gesamten Code von einem oder mehreren Modulen speichert.
Der Begriff „Speicherschaltung“ ist eine Untermenge des Begriffs „computerlesbares Medium“. Der Begriff „computerlesbares Medium“, wie er hier verwendet wird, umfasst keine transitorischen elektrischen oder elektromagnetischen Signale, die sich durch ein Medium (z.B. auf einer Trägerwelle) ausbreiten); der Begriff „computerlesbares Medium“ kann daher als greifbar/materiell und nicht-transitorisch betrachtet werden. Nicht einschränkende Beispiele für ein nicht-transitorisches, greifbares, computerlesbares Medium sind nichtflüchtige Speicherschaltungen (z.B. eine Flash-Speicherschaltung, eine löschbare, programmierbare Festwertspeicherschaltung oder eine Maskenfestwertspeicherschaltung), flüchtige Speicherschaltungen (z.B. eine statische Direktzugriffsspeicherschaltung oder eine dynamische Direktzugriffsspeicherschaltung), magnetische Speichermedien (z.B. ein analoges oder digitales Magnetband oder ein Festplattenlaufwerk) und optische Speichermedien (z.B. eine CD, eine DVD oder eine Blu-ray Disc).
Die in dieser Anwendung beschriebenen Geräte und Verfahren können teilweise oder vollständig von einem Spezialcomputer implementiert werden, der durch Konfiguration eines Allzweckcomputers zur Ausführung einer oder mehrerer bestimmter, in Computerprogrammen verkörperter Funktionen gebildet wird. Die oben beschriebenen Funktionsblöcke, Flussdiagrammkomponenten und andere Elemente dienen als Softwarespezifikationen, die durch die Routinearbeit eines erfahrenen Technikers oder Programmierers in die Computerprogramme übersetzt werden können.
Die Computerprogramme enthalten prozessorausführbare Befehle, die auf mindestens einem nicht-transitorischen, greifbaren, computerlesbaren Medium gespeichert sind. Die Computerprogramme können auch gespeicherte Daten enthalten oder auf diese zurückgreifen. Die Computerprogramme können ein Basis-Eingabe/Ausgabe-System (BIOS) umfassen, das mit der Hardware des Spezialcomputers interagiert, Gerätetreiber, die mit bestimmten Geräten des Spezialcomputers interagieren, ein oder mehrere Betriebssysteme, Benutzeranwendungen, Hintergrunddienste, Hintergrundanwendungen usw.
Die Computerprogramme können enthalten: (i) beschreibenden Text, der geparst werden soll, z.B. HTML (Hypertext Markup Language), XML (Extensible Markup Language) oder JSON (JavaScript Object Notation) (ii) Assembler-Code, (iii) von einem Compiler aus dem Quellcode generierten Objektcode, (iv) Quellcode zur Ausführung durch einen Interpreter, (v) Quellcode zur Kompilierung und Ausführung durch einen Just-in-Time-Compiler usw. Nur als Beispiele: Der Quellcode kann mit der Syntax von Sprachen wie C, C++, C#, ObjectiveC, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, SIMULINK und Python® geschrieben sein.

Claims

System, umfassend: eine Warteschlange, die so konfiguriert ist, dass sie eine Nachricht zwischen einem ersten Thread und einem zweiten Thread überträgt, wobei der erste Thread und der zweite Thread als Teil eines einzelnen Prozesses implementiert sind und wobei eine der Nachricht entsprechende Datenmenge kleiner als eine festgelegte Datenmenge ist; einen Speicher, der für die gemeinsame Nutzung von Daten zwischen dem ersten Thread und dem zweiten Thread konfiguriert ist, wobei die zwischen dem ersten Thread und dem zweiten Thread gemeinsam genutzte Datenmenge größer ist als die festgelegte Datenmenge; und einen Controller, der so konfiguriert ist, dass er den einzelnen Prozess ausführt, der die gleichzeitige Ausführung (i) eines ersten Middleware-Knoten-Prozesses als ersten Thread und (ii) eines zweiten Middleware-Knoten-Prozesses als zweiten Thread umfasst.
System nach Anspruch 1, wobei der erste Thread und der zweite Thread den gleichen Bereich eines Hauptspeicheradressraums des Speichers für Thread-Code, Thread-Daten, Grafikverarbeitungsmodul-Code und Grafikverarbeitungsmodul-Daten gemeinsam nutzen.
System nach Anspruch 1, ferner umfassend ein Grafikverarbeitungsmodul mit einem Ausführungsmodul, das so konfiguriert ist, dass es Code für den ersten Thread gleichzeitig mit Code für den zweiten Thread ausführt.
System nach Anspruch 1, ferner umfassend ein Grafikverarbeitungsmodul, das ein Kopiermodul umfasst, das so konfiguriert ist, dass es Grafikverarbeitungsmodul-Daten für den ersten Thread gleichzeitig mit Grafikverarbeitungsmodul-Daten für den zweiten Thread kopiert.
System nach Anspruch 1, ferner umfassend: einen Speicher für ein Grafikverarbeitungsmodul; und ein Grafikverarbeitungsmodul, das so konfiguriert ist, dass es gleichzeitig Daten für den ersten Thread und den zweiten Thread zwischen einem Hauptspeicheradressraum des Speichers und dem Speicher des Grafikverarbeitungsmoduls überträgt.
System nach Anspruch 1, ferner umfassend ein Grafikverarbeitungsmodul, wobei: der erste Thread erste Berechnungen für einen ersten Algorithmus des ersten Middleware-Knotens erzeugt; und der zweite Thread zweite Berechnungen für einen zweiten Algorithmus des zweiten Middleware-Knotens erzeugt; und das Grafikverarbeitungsmodul gleichzeitig die ersten Berechnungen für einen zweiten Frame ausführt, während es die zweiten Berechnungen für einen ersten Frame ausführt, wobei der zweite Frame nach dem ersten Frame erfasst und empfangen wird.
System nach Anspruch 1, wobei der erste Thread und der zweite Thread als Teil eines einzelnen Middleware-Knotens implementiert sind.
System nach Anspruch 1, wobei der Controller so konfiguriert ist, dass er: einen Hauptspeicheradressraum des Speichers, der von dem ersten Thread und dem zweiten Thread gemeinsam genutzt werden soll, zuweist und festlegt; und die vom ersten Thread und zweiten Thread zu verwendende Warteschlange festlegt.
System nach Anspruch 8, wobei: der Hauptspeicheradressraum für Lese- und Schreiboperationen dediziert ist; und die Warteschlange für Sende- und Empfangsoperationen dediziert ist.
System nach Anspruch 1, wobei der Controller so konfiguriert ist, dass er: feststellt, ob die Verwendung der Warteschlange angemessen ist, und gegebenenfalls eine Verbindung mit der Warteschlange herstellt, falls sie zugewiesen ist, und die Warteschlange zuweist, wenn sie nicht zugewiesen war; und feststellt, ob die Verwendung eines gemeinsam genutzten Bereichs des Speichers angemessen ist, und gegebenenfalls auf den gemeinsam genutzten Bereich zugreift, wenn er zugewiesen ist, und den gemeinsam genutzten Bereich zuweist, wenn er nicht zugewiesen war.