Zusätzliche Ressourcen ausschöpfen Windows Embedded Compact 7: Facelifting auch unter der Oberfläche

Bild 3. Windows Embedded Compact 7 verwaltet bis zu 3 Gbyte phyischen Speicher – hier in einem „Virtual PC“, auf dem 2 Gbyte mit 2 Gbyte verfügbarem RAM.
Bild 3. Windows Embedded Compact 7 verwaltet bis zu 3 Gbyte phyischen Speicher – hier in einem „Virtual PC“, auf dem 2 Gbyte mit 2 Gbyte verfügbarem RAM.

Embedded-Geräte sind in den letzten Jahren leistungsfähiger geworden: Mehr Rechenkerne und mehr Speicher sind dank Preisverfall kein Luxus mehr. Windows Embedded Compact 7 kann durch ein überarbeitetes Innenleben den Nutzen dieser zusätzlichen Ressourcen ausschöpfen.

Die Zuverlässigkeit eines Computersystems hat immer einen hohen Stellenwert, doch bei Embedded-Systemen ist sie unabdingbar. Windows Embedded Compact 7 schafft deshalb ein hochzuverlässiges Fundament für moderne Embedded-Systeme.

Compact 7, die  neueste Ver­sion von Windows Embedded CE, ist ausgestattet mit einem aktualisierten ­Kernel, einem neuen Netzwerk-Stack, aktualisierten Tools und einer Viel­-
zahl weiterer neuer Merkmale. Neben dem aktualisierten Betriebssystem wurde auch das Entwicklungswerkzeug „Platform Builder for Windows Embedded Compact 7“ verbessert, um komfortable Unterstützung für Entwicklung, Debugging und Support zu bieten.

Der Multi-Core-Kernel

Ausgangspunkt der Verbesserungen ist ein modernisierter Kernel, der nun Unterstützung für das symmetrische Multiprocessing (SMP) enthält, sodass mehrere CPU-Cores gleichzeitig genutzt werden können. Hierzu werden die Threads auf die verschiedenen Cores der CPU verteilt. Um die neuen Multi-Core-Fähigkeiten des Betriebssystems demonstrieren zu können, wurde eine CPU-Load-Applikation entwickelt, wie sie in ähnlicher Form auch für die Desktop-Versionen von Windows existiert. Bild 1 zeigt den System-Monitor der Applikation während der Internet Explorer Embedded eine Internetseite lädt. Man erkennt deutlich, wie der Kernel jeden Prozessorkern dieses Multi-Core-Systems nutzt.

Von der Performance abgesehen, besteht der wichtigste Vorteil des symmetrischen Multiprocessings da­rin, dass ein einzelner außer Kontrolle geratener Thread nicht die Leistungsfähigkeit des gesamten Systems beeinträchtigen kann. Wenn ein einzelner Thread in der Vergangenheit nicht das ganze System blockierte, hatte er – selbst wenn er mit normaler Applikations-Priorität lief – spürbare Auswirkungen auf die Benutzeroberfläche und auf die Performance vieler anderer im Hintergrund laufender Threads. In einem SMP-System verbraucht ein solcher außer Kontrolle geratener Thread zwar die Verarbeitungskapazität eines Cores, doch die übrigen Cores der CPU stehen dem Betriebssystem nach wie vor für andere Applikationen zur Verfügung.

Das Listing gibt ein triviales Beispiel für solch ein Horror-Szenario in einem Embedded-System wieder. In einem Single-Core-System würde der Code die Leistungsfähig­keit gravierend beeinträchtigen. In Bild 2 gibt der CPU-System-Monitor die CPU-Auslastung der außer Kon­trolle geratenen Applikation in diesem Szenario wieder. Wie man sieht, weist das Display für CPU 1 eine Auslastung von 100 % aus, während die übrigen Cores weiter verfügbar sind. Im vorliegenden Fall lädt der Internet Explorer eine Internet-Seite und zeigt sie an. Das System reagiert zudem uneingeschränkt auf die Benutzeroberfläche und auf die anderen Applikationen im System, obwohl die außer Kontrolle geratene Applika­tion weiter läuft.

Von der Programmierung her gesehen hat der Multi-Core-Support keine Auswirkungen auf Single-Threaded-Applikationen. Die Applikation kann die Zahl der in einem System verfügbaren Cores mit der Funktion CeGetTotalProcessors erfragen.  Während also Single-Threa­ded-Applikationen keine weiteren Überlegungen erfordern, können Multi-Core-Systeme für Multi-Threaded-Applikationen durchaus Konsequenzen haben. Bei Multi-Threaded-Applika­tionen, die nicht auf Multi-Core-Systemen getestet wurden, kann es nämlich zu Timing-Problemen kommen, wenn sich die Threads nicht mehr einen Core teilen müssen, sondern gleichzeitig auf mehreren separaten Cores laufen. Um diese Probleme zu vermeiden, kann eine Applikation für eine frühere Version des Betriebssystems compiliert werden, so dass alle Threads ein und demselben Core zugewiesen werden.

Bei Anwendungen, die eigens für Windows Embedded Compact 7 compiliert werden, wird davon ausgegangen, dass sie für Multi-Core-Systeme getestet sind und ihre Threads dementsprechend auf alle Cores verteilt werden dürfen. Falls in die Thread-Zuweisung gezielt eingegriffen werden muss, kann die Vergabe eines Threads an einen bestimmten Core mithilfe des Application Programming Interface (API) CeSetThreadAffinity vorgenommen werden. Um alle Threads eines Prozesses einem bestimmten Core zuzuweisen, wird die Funktion CeSetProcessAffinity benutzt.
Selbstverständlich gibt es auch die entsprechenden Funktionen zum Abfragen der Affinität (CeGetThreadAffinity und CeGetProcessAffinity). Außerdem wurde die neue Funktion GetIdleTimeEx hinzugefügt, mit der Applikationen die Leerlaufzeit für jeden Core einzeln abfragen können.

Abgesehen von den Prozessen und Threads können Embedded-Ingenieure auch die Cores der CPU verwalten. Vom primären Core der CPU abgesehen, lassen sich alle Cores in den Power-Down-Status versetzen und je nach Bedarf wieder aktivieren. Die entsprechenden APIs zur Steuerung heißen CePowerOffProcessor und CePowerOnProcessor.