Reduzierter Rechenaufwand durch Preemption-Threshold Scheduling (PTS)

Anbieter zum Thema

ROHM Semiconductor GmbH

TRACO ELECTRONIC GMBH

IBR Leiterplatten GmbH & Co. KG

Express Logic, Inc

Express Logic GmbH

Im vorliegenden Beispiel könnte ein Thread mit der Priorität 20 von einem Thread unterbrochen werden, dessen Prioritätswert 19, 18, 17 usw. lautet. Wäre aber die Preemption Threshold des Threads auf 15 eingestellt, wäre eine Präemption nur durch Threads mit einer höheren Priorität als 15 (also einer niedrigeren Prioritätszahl) zulässig. Eine Präemption durch Threads mit den Prioritäten 19, 18, 17, 16 und 15 wäre somit ausgeschlossen, während sie bei Prioritäten von 14 und höher (also niedrigeren Prioritätszahlen) erlaubt wäre. Die Angabe einer Preemption Threshold ist optional und kann für alle Threads, bestimmte Threads oder keine Threads erfolgen. Ist kein Preemption-Threshold-Wert spezifiziert, können Präemptionen durch alle Threads mit höherer Priorität erfolgen. Ist dagegen eine Preemption Threshold angegeben, sind Präemptionen nur durch Threads zulässig, deren Priorität höher ist als der angegebene Wert.

Performance-Vorteile des PTS-Verfahrens

Um Einblick in die Abläufe der Applikation zu bekommen, werden alle Ereignisse aufgezeichnet. Aus den Aufzeichnungen werden anschließend die Zahl der Kontextwechsel und die verstrichene Zeit abgelesen, sodass Rückschlüsse gezogen werden können. Zum Vergleich beider Verfahren werden zwei Fälle betrachtet:

• In Fall 1 wird das vollständig präemptive Scheduling verwendet. Die Threads A, B, C und D haben die Prioritäten 1, 2, 3 und 4.

• In Fall 2 ist die Ausgangsposition gleich. Aber das PTS-Verfahren kommt ins Spiel, um zu sehen, wie sich die Zahl der Kontextwechsel damit reduzieren lässt. Zu diesem Zweck erhält der Thread D einen Preemption-Schwellwert von 1, sodass dieser Thread nur von einem Thread unterbrochen werden kann, dessen Priorität höher als 1 ist. Da es in diesem System keinen Thread mit der Priorität 0 gibt, ist diese Bedingung nie erfüllt, so dass der Thread D von den Strängen A, B oder C nicht unterbrochen wird.

In Fall 1 beginnt der Thread D mit dem Senden von Meldungen an die einzelnen Queues, doch sobald die erste Meldung gesendet ist, wird Thread A aktiv, um diese Meldung abzurufen. Thread A nämlich besitzt eine höhere Priorität als Thread D, und da die Warteschlange, auf die er gewartet hat, nun nicht mehr leer ist, ist Thread A zur Ausführung bereit. Hat Thread A die Meldung gelesen, wechselt er wegen der nunmehr wieder leeren Warteschlange erneut in den Wartestatus, sodass Thread D seine Arbeit wieder aufnehmen kann und eine Meldung an Thread B sendet, der daraufhin sofort Thread D unterbricht. So geht es weiter, bis alle neun Meldungen gesendet sind und der Zyklus beendet ist. Während dieses Durchlaufs wurden neun Meldungen gesendet, neun empfangen und 18 Kontextwechsel ausgeführt.

In Fall 2 sendet der Thread D seine Meldungen weiter, bis er auf eine nicht leere Warteschlange trifft und infolgedessen wartet, bis die Warteschlange wieder leer ist. Sobald Thread D stoppt, wird er nicht wieder gestartet, bis die Threads A, B und C angehalten werden, da er mit seiner Priorität 4 keinen anderen Thread unterbrechen kann.

Das Ergebnis von Fall 2 unterscheidet sich grundlegend von Fall 1, denn hier kommt es nur zu vier Kontextwechseln, während es im ersten Fall 18 waren. Eindrucksvoll ist auch ein Vergleich der Anzahl an Timer-Ticks. Sind es in Fall 1 insgesamt 1.801 Ticks, beträgt die Zahl in Fall 2 nur 964.

* * John A. Carbone ist Vice President für Marketing beim Betriebssystemhersteller Express Logic. Er lebt und arbeitet im kalifornischen San Diego.

(ID:37563520)