Bild 2: Aufbau eines Hyerthreading-Prozessors: Die Maschinenbefehle zweier Programme werden in einem Hyperthreading-Prozessor so verteilt, dass diese optimal ausgelastet sind.

© Siemens

Während der Ausführung durchläuft ein Befehl die sogenannten Pipeline-Stufen. Diese übernehmen einzelne Aufgaben wie das Lesen des Befehls oder dessen Decodierung. Letztere verteilt ihn auf die oben genannten Einheiten, die den Befehl ausführen und damit auch in einem Single-Core voll parallel arbeiten können. Über vorgeschaltete Puffer können einer Einheit auch mehrere Befehle ohne Wartezyklen zugeteilt werden. Dadurch wird ein Durchsatz von bis zu einem Befehl pro Taktzyklus erreicht, obwohl die Ausführung der einzelnen Befehle meist mehrere Zyklen dauert.

In einem Hyperthreading-Prozessor besteht ein physikalischer Rechenkern aus zwei logischen Kernen, deren einfache Einheiten auch doppelt vorliegen, während die komplexen Einheiten nur einmal vorhanden sind. Die Software sieht den Unterschied zunächst nicht und nutzt diese logischen Kerne genauso wie physikalische. Beide Kerne haben eine eigene Befehlsliste (instruction queue), in der die Maschinenbefehle des Programms stehen. Diese beiden Listen werden in der Pipeline-Sequenz vermischt, um die vorhandenen Einheiten optimal – also möglichst permanent – auszulasten. Dazu werden die Befehle nicht abwechselnd aus beiden Listen genommen, sondern abhängig vom aktuellen Belegungsgrad der Einheiten.

Die linke Seite in Bild 2 zeigt dieses Verfahren und veranschaulicht, wie aus einer deterministischen Reihenfolge einer Befehlsliste eine zufällige und in der Reihenfolge nicht mehr vorhersagbare Liste wird. Für die Software bedeutet dies, dass ihre Laufzeit noch stärker von dem Programm auf dem anderen logischen Rechenkern abhängt. Da dieses Programm bei jeder Messung ein anderes sein wird, ist die Laufzeit nicht bestimmbar.

Die Messwerte zeigen die Auswirkungen von Hyperthreading.

© Siemens

Um die Maximalwerte der Laufzeit zu messen, wurde auf einem solchen Prozessor ein Echtzeit-System installiert. In der Anwendung laufen zwei Threads – einer mit (RT = Real-Time) und einer ohne (NRT = Non-Real-Time) Echtzeit-Eigenschaften. Der RT-Thread wird wie ein Regler zyklisch über einen Software-Timer aktiviert, während der NRT-Thread im Hintergrund auf dem anderen logischen Kern läuft.

Die Messwerte in der Tabelle zeigen die Auswirkungen von Hyper­threading auf die Laufzeit eines Echtzeit-Threads. Läuft dieser alleine auf einem logischen Kern, so ist seine Laufzeit relativ konstant, wobei sich durch Betriebssystemprogramme auf dem zweiten logischen Kern die maximale Laufzeit dennoch erhöht. Läuft auf dem zweiten logischen Kern hingegen der NRT-Thread, so dass beide Threads sich die FPU teilen müssen, liegt die maximale Laufzeit annähernd bei dem doppelten Wert des ungestörten Betriebs und selbst der Mittelwert liegt deutlich näher am maximalen statt am minimalen Wert.

Aus diesem Grund wird bei Echtzeit-Anwendungen Hyperthreading abgeschaltet; zumindest auf den physikalischen Kernen, auf denen zeitkritische Programme laufen. Dadurch wird jedoch Rechenleistung verschenkt, die sich für Nicht-Echtzeit-Anwendungen nutzen ließe.

Vorfahrtsregeln für Multicore

Zur Nutzung dieser Rechenleistung wurde in das Echtzeit-Betriebssystem ein Mechanismus eingebaut, der den Echtzeit-Threads entsprechend Vorfahrt einräumt. Das System muss zunächst die Threads klassifizieren können, um diese Entscheidung zu treffen. Des Weiteren wurde die Gesamtapplikation so verteilt, dass alle Echtzeit-Threads auf einem logischen Kern ablaufen, während die Nicht-Echtzeit-Threads sich auf beide logischen Kerne verteilen.

Bild 3. Kontrolle des Echtzeit-Verhaltens: Der Einfluss des Programms auf dem zweiten Rechenkern kann kontrolliert werden, indem dort ein bekanntes „Programm“ (die Warteschleife) ausgeführt wird, während das Echtzeit-Programm läuft.

© Siemens

Wird ein RT-Thread durch ein Ereignis (Timer, Interrupt etc.) aktiviert, so schickt das Betriebssystem eine Meldung an den zweiten logischen Kern. Dies kann beispielsweise als Interrupt (Inter Processor Interrupt – IPI) erfolgen, damit dieser Kern möglichst schnell seinen aktuell laufenden NRT-Thread unterbricht und in eine Warteschleife verzweigt. In dieser Schleife liest der Kern beispielsweise den Inhalt einer lokalen Speicherzelle. Somit werden zum einen nur Prozessoreinheiten verwendet, die jeder logische Kern besitzt, und zum anderen erfolgen keine Zugriffe auf Peripherie außerhalb des Prozessors, die – wie zuvor beschrieben – den anderen Kern ausbremsen können. Selbst ein konkurrierender Speicherzugriff lässt sich ausschließen, da die zu lesende Speicherzelle spätestens nach dem ersten Zugriff im Cache liegt.

Die linke Seite in Bild 3 zeigt das Verfahren aus Applikationssicht. Sobald ein RT-Thread gestartet wird, wird der zweite logische Kern in die Warteschleife gezwungen. Auf der rechten Seite ist dieses Vorgehen aus Prozessorsicht dargestellt, insbesondere die Füllung der Prozessor-Pipeline. Wenn auf beiden logischen Kernen nur NRT-Threads laufen, ist die Reihenfolge der Befehle zufällig und nicht vorhersagbar. Läuft hingegen ein RT-Thread und parallel dazu die Warteschleife, so mischen sich aufgrund der exklusiv im zweiten logischen Kern zur Verfügung stehenden Einheiten die Befehle de­terministisch. Die Laufzeit des RT-Threads ist  damit vollständig vorhersagbar, wie die Messwerte in der Tabelle (unten) zeigen.

Messwerte der laufzeit eines RT-Threads

© Siemens

Selbst wenn der RT-Thread alleine läuft, verbessert sich die Deterministik seiner Laufzeit erheblich, da auch alle Betriebssystem-Aktivitäten auf dem zweiten Kern durch die Warteschleife unterbunden werden. Im Falle eines NRT-Threads auf dem zweiten Kern, der die gleichen Prozessoreinheiten verwendet, ist die Verbesserung noch signifikanter, da keine nennenswerte Verschlechterung der Messwerte mehr auftritt.

Das beschriebene Verfahren lässt sich nicht nur für Hyperthreading-Prozessoren anwenden, sondern kann auch bei echten Multicore-Prozessoren dazu dienen, Peripheriezugriffe auf anderen Kernen sicher auszuschließen, wenn auf einem Kern zeitkritische Software läuft. Der Vorteil gegenüber den oben genannten Maßnahmen ist, dass die Applikation nicht verändert werden muss beziehungsweise auch nicht im Quellcode vorliegende Software kontrollierbar ist.

Genaue Kenntnis der Hardware unabdingbar

Wie die bisherigen Ausführungen zeigen, birgt die Verwendung von Multicore-Prozessoren in der Automatisierungstechnik sehr viele Chancen und kann den Trend zu mehr Leistung in den Steuerungen unterstützen. Auf der anderen Seite bringen diese Prozessoren neue Probleme mit sich, die in den bisherigen Anwendungsgebieten nicht relevant waren.

Daher lässt sich die Software eines Automatisierungsgerätes nicht mehr ohne genaue Kenntnis der zugrunde­liegenden Hardware entwickeln, da diese implizite Abhängigkeiten enthalten kann, die vielleicht nicht zwingend die Funktion, aber mit Sicherheit das Zeitverhalten der Software negativ beeinflussen. Mit anderen Worten: Weil in Echtzeit-Systemen die Daten nicht nur inhaltlich, sondern auch zeitlich korrekt sein müssen, kann der Umstieg auf Multicore-Prozessoren zu Fehlverhalten der Software führen, selbst wenn dabei zwei mehr oder weniger unabhängige Anwendungen auf einem Prozessor mit mehreren Kernen konsolidiert werden.

Die Lösung ist entweder die Anpassung der Software sowie die explizite Verwaltung von eigentlich eher unsichtbaren Hardware-Ressourcen wie Speicher und Bussystemen oder die Ertüchtigung des Betriebssystems dahingehend, die kritische Software zu erkennen und entsprechend auf Basis definierter Vorfahrtsregeln zu bevorzugen.

Autor: Dr. René Graf ist Gruppenleiter Vorfeldentwicklung bei Siemens.