Anbieter zum Thema

Express Logic, Inc

MicroConsult Academy GmbH

MES Electronic Connect GmbH & Co. KG

Selektives Scheduling

Ein bemerkenswertes Feature von ThreadX ist der Preemption-Threshold-Mechanismus. Was ist der nützlichste Aspekt dieses Features?

Eigentlich haben alle Echtzeitbetriebssysteme die Fähigkeit, den Scheduler abzuschalten, wenn auf dem Thread-Level nichts Anderes laufen soll. Das schafft eine „sichere Periode“, während der das RTOS kritische Code-Sequenzen ausführen kann, die vollständig ausgeführt werden müssen, um die Konsistenz zu sichern. Typischerweise wird das mit einem API-Aufruf erledigt, der das ganze Thread-Scheduling anhält, bis ein weiterer API-Call erfolgt, der das Scheduling wieder erlaubt.

Bei der Entwicklung von ThreadX dachte ich mir, dass es nett wäre, hier ein bisschen selektiver vorgehen zu können. Nach meiner Erfahrung muss nur eine bestimmte Klasse von Threads oder Prioritäten davon abgehalten werden, ausgeführt zu werden, um die Integrität kritischer Codefolgen zu sichern. Preemption-Threshold Scheduling erlaubt es dem Entwickler, einen Bereich von Prioritäten zu wählen, für den das Scheduling abgeschaltet wird, während es Threads höherer Priorität weiterhin erlaubt ist zu unterbrechen, um eine kritische Code-Sektion abzuarbeiten. Es ist ein etwas feinkörnigerer Mechanismus, als ihn andere Betriebssysteme verwenden, den ich mir während der Entwicklung von ThreadX ausdachte. Es hat sich gezeigt, dass das ein hübscher Benefit ist, den viele Embedded-Entwickler heute verwenden.

In Diskussionen über den Preemption-Threshold-Mechanismus wird zum Teil befürchtet, dass Echtzeitsysteme ihren deterministischen Charakter verlieren könnten, sobald dieses Feature verwendet wird. Wie würden Sie das sehen?

Ganz im Gegenteil! Verschiedene akademische Institute auf der ganzen Welt haben das Preemption-Threshold-Verfahren studiert und mathematisch bewiesen, dass es ein vollkommen deterministisches Systemverhalten ermöglicht und dem System erlaubt, alle Echtzeit-Deadlines garantiert einzuhalten.

Es gibt eine gewisse Verwirrung um die Tatsache, dass die Präemptionsschwelle dazu genutzt werden kann, um eine Präemption zu verhindern, die sonst erfolgen würde, und dass diese Verhinderung zu irgendeinem Verlust an Determinismus oder Echtzeit-Antwortzeit führen könnte. Sicher, das wäre dann möglich, wenn der Anwender Preemption-Threshold falsch oder zum falschen Zeitpunkt verwenden würde.

Das ist nicht anders als bei vielen anderen Benutzeraktionen, die in Konflikt mit dem Determinismus eines Systems geraten können. Zum Beispiel kann die Zuweisung einer falschen Priorität an einen Thread diesen Strang wertlos machen, und das System würde dadurch nicht-deterministisch.

Der Schlüssel liegt darin, zu verstehen, dass Preemption-Threshold-Scheduling, wie alle Dienste eines RTOS, richtig verwendet werden muss, damit es die Fähigkeit des Systems nicht schmälert, alle Echtzeit-Deadlines einzuhalten und ein deterministisches Verhalten zu gewährleisten. Es wurde bewiesen, dass dies möglich ist, aber die Entwickler müssen ihren Teil dazu beitragen, die Technik korrekt anzuwenden.

Sehen Sie noch Möglichkeiten zur Verbesserung für ThreadX?

Wir verbessern ThreadX kontinuierlich, wenn immer wir etwas finden, das besser gemacht werden könnte. Oft liefert dafür eine Anfrage eines Anwenders den Anstoß, bei der wir finden, dass sie allgemein nützlich ist und keine ernsthaften Nachteile in Form von Verwaltungs-Overhead oder Änderungen in der Benutzer-Erfahrung nach sich zieht.

Aber das weit größere Gebiet, in dem ständige Verbesserung stattfindet, sind unsere Middleware-Produkte und Entwicklungswerkzeuge, vor allem in den Bereichen Systemanalyse, Grafik, Netzwerk-, und USB- Kommunikation. In all diesen Bereichen investieren wie signifikante Ressourcen und machen große Anstrengungen, um unsere Produkte zu den besten in der Industrie zu machen. Wir haben all diese Produkte in-house entwickelt, und wir liefern dafür auch den Support.

Unser grafisches Echtzeit-Event-Analysewerkzeug TraceX erlaubt Entwicklern, exakt zu sehen, was ihr System in letzter Zeit getan hat. Es ist wie die Black Box in einem Flugzeug, die alle Flugdaten kontinuierlich aufzeichnet, und die von kritischer Bedeutung ist, wenn es darum geht, die Ursache eines Unfalls zu analysieren

Unsere Netzwerksoftware NetX und NetX Duo hat kürzlich auf einem Xilinx Zynq-7000-Multicore-System auf Basis eines Cortex A9 fast dieselbe Geschwindigkeit wie bei einem Kabelnetzwerk erreicht, wir haben außerdem Near-Wire-Geschwindigkeiten bei einem STM32, einem Cortex M3-basierten Prozessor, erreicht. Daran können Sie sehen, dass auch Lowend-Prozessoren hervorragende Netzwerk-Geschwindigkeiten mit NetX erreichen können.

Und last but not least unterstützt unser USBX-Stack eine große Vielzahl an Prozessoren und eröffnet vielen Host- und Geräteklassen eine breite Palette von USB-Kommunikationsanwendungen.

(ID:37979540)