DE10143983A1 - Verfahren zur Steuerung der Abarbeitung medienverarbeitender Prozesse auf einem Datenprozessor - Google Patents

Abstract

Verfahren zur Steuerung der Abarbeitung medienverarbeitender Prozesse auf einem Datenprozessor oder einer zusammenwirkenden Datenprozessorgruppe, wobei dem oder jedem medienverarbeitenden Prozeß eine Prioritätsstufe einer vorbestimmten Skala von Prioritätsstufen zugewiesen wird, die prioritätshöchsten Prozesse ohne vorab festgelegtes Zeitlimit bevorzugt abgearbeitet werden, die Prozessorlast spezifisch bestimmt und überwacht und eingeschränkt wird, wenn sie einen vorbestimmten ersten Grenzwert überschreitet.

Description

• Die Erfindung betrifft ein Verfahren zur Steuerung der Abarbeitung medienverarbeitender Prozesse auf einem Datenprozessor.
• Arbeitsplatz-Rechner (PCs oder Workstations) werden schon seit längerem nicht nur zur Datenverarbeitung eingesetzt. Solche Geräte dienen immer häufiger auch als Kommunikationsgerät, so kann man z. B. heute mit einem PC und geeigneter Software über das Internet telefonieren. Solche Anwendungen verarbeiten Video- und Audiodaten (sogenannte kontinuierliche Daten), diese erfordern jedoch die Berücksichtigung von Realzeit-Bedingungen. Es muß gewährleistet sein, daß solche Daten zeitlich gleichmäßig und mit einer möglichst geringen Verzögerung verarbeitet werden. Letzteres ist insbesondere für die interaktive Kommunikation von Mensch zu Mensch erforderlich (z. B. beim Telefonieren). Die Architektur heutiger Arbeitsplatz-Rechner und die hier eingesetzten Betriebssysteme sind jedoch nicht darauf ausgelegt diskrete Daten (ohne Bezug zur Realzeit) zu verarbeiten. Kontinuierliche Daten werden auf solchen Systemen verarbeitet, indem sie in eine Folge von diskreten Dateneinheiten zerlegt werden (logical data units: LDU). Realzeitanforderungen für die Verarbeitung einzelner LDUs werden nicht berücksichtigt oder gar garantiert. Beispiele von Realzeitanforderungen sind: "die Verarbeitung einer LDU muß bis zu einem bestimmten Zeitpunkt (deadline) abgeschlossen sein" oder "die Verarbeitungszeit für eine LDU darf ein gegebenes Zeitintervall nicht überschreiten".
• Auf einem Arbeitsplatz-Rechner konkurrieren üblicherweise mehrere Prozesse um den Zugriff auf die CPU Ressource(n). Neben den von Nutzern gestarteten Anwendungen sind in der Regel noch eine Vielzahl von Service-Prozessen aktiv. Ein Prozeß darf eine CPU für ein festgelegtes Zeitintervall belegen, spätestens nach Ablauf dieses Zeitintervalls wird die CPU einem anderen Prozeß zugeordnet. Das Umschalten von einem Prozeß auf einen anderen (Kontextwechsel) übernimmt der sogenannte Dispatcher. Die Reihenfolge, in der die Prozesse der/den CPU(s) zugeordnet werden, legt ein Prozeß-Scheduler nach bestimmten Verfahren fest (Schedulingstrategie). Heute übliche Betriebssysteme für Arbeitsplatz-Rechner verwenden Schedulingstrategien, die auf veränderbaren Prozeß- Prioritäten beruhen. Diese Strategien berücksichtigen keinerlei Realzeit-Anforderungen der Prozesse.
• Es werden spezielle Prozeß-Scheduler verwendet, welche aufgrund ihrer Schedulingstrategie die Realzeit-Anforderungen medienverarbeitender Prozesse berücksichtigen können. D. h. es wird versucht, die Verteilung der verfügbaren CPU-Zeit explizit zu steuern. Da der Prozeß-Scheduler eine zentrale und essentielle Komponente jedes Betriebssystems darstellt, ist es in der Regel schwierig, diese Komponente auszutauschen bzw. zu verändern. (Einige Betriebssysteme unterstützen die Erweiterung des Prozeß-Scheduler, z. H. das Unix Betriebssystem Solaris, die weit verbreiteten Windows Betriebssysteme bieten diese Möglichkeit jedoch nicht an.)
• Idealerweise sollten Hersteller von Betriebssystemen bereits Prozeß-Scheduler vorsehen, die Realzeit-Anforderungen von Prozessen unterstützen können. Entsprechende Scheduler werden in der Literatur beschrieben.
• In der Praxis hat sich jedoch gezeigt, daß auch moderne Varianten der weit verbreiteten Betriebssysteme für Arbeitsplatz-Rechner solche Scheduler nicht bereitstellen. Um trotzdem Realzeit-Anforderungen berücksichtigen zu können, können sogenannte Meta-Scheduler verwendet werden. Diese steuern durch die Veränderung von Prozessprioritäten das Verhalten des Betriebssystem-eigenen Prozeß-Schedulers. Die Nachteile dieser Vorgehensweise sind:
  
• - Es ist notwendig die Prioritäten der Prozesse sehr häufig zu ändern. Dies ist mit einem hohen Rechenaufwand verbunden.
• - Manche betriebsystem-eigene Scheduler verändern ebenfalls die Prozeß-Prioritäten, jedoch mit einer anderen Zielsetzung, als der Unterstützung von Realzeit-Prozessen (z. B. die Scheduler der Windows Betriebssysteme). Ein Meta-Scheduler wurde daher kontraproduktiv zum Betriebssystem-eigenen Scheduler arbeiten, dies erschwert die Realisierung eines Meta-Schedu-lers.
• Bei der Verwendung eines Prozess-Schedulers, der Realzeit-Anforderungen berücksichtigen soll, stellt sich allgemein das Problem, daß eine genaue Beschreibung der Realzeit-Anforderungen in der Regel nicht bekannt ist. So ist beispielsweise die Bearbeitungszeit für eine LDU meist nicht bekannt, da dieser Wert von der Verarbeitungsleistung des jeweiligen Systems abhängt. Selbst wenn dieser Wert statistisch ermittelt worden ist, kann dennoch die Bearbeitungszeit für einzelne LDUs stark abweichen.
• In der Praxis ist es daher heute üblich, keine speziellen Scheduler zu verwenden. Es wird darauf vertraut, daß die Performanz der üblichen Arbeitsplatz-Rechner ausreichend ist für die Verarbeitung von kontinuierlichen Medien. Falls ein Arbeitsplatz-Rechner ausschließlich für diesen Zweck eingesetzt wird, ist dies meistens auch der Fall.
• Problematisch ist aber weiterhin der Fall, wenn auf einem Arbeitsplatz-Rechner neben der Medienverarbeitung weitere aktive Prozesse existieren. In diesem Fall werden die medienverarbeitenden Prozesse aufgrund der Schedulingverfahren immer wieder von anderen Prozessen ohne Realzeitbezug unterbrochen. Man sagt die Prozesse arbeiten quasi-parallel, da der Wechsel zwischen den Prozessen derart schnell geschieht (z. B. alle 10 ms), daß ein Benutzer den Eindruck hat, die Prozesse würden gleichzeitig auf einem Rechner ablaufen. Dadurch vergrößert sich die Bearbeitungszeit einer LDU und damit die Verzögerung des gesamten Datenstromes. Insbesondere für die interaktive Kommunikation von Mensch zu Mensch ist es jedoch wichtig, möglichst kurze Verzögerungszeiten zu erreichen, damit eine für den Menschen angenehme Kommunikation möglich ist. Abhängig von der Anzahl und Art der Anwendungen, die ein Nutzer neben den medienverarbeitenden Prozessen nutzt, kann es zu einer mehr oder weniger starken "Störung" durch diese non-realtime Prozesse kommen. Zu starke "Störungen" führen dazu, daß Teile des Medienstromes nicht rechtzeitig ausgegeben werden können. Die Folge sind hörbare Unterbrechungen der Audioausgabe oder das Fehlen einzelner Videobilder. Letzteres wird in der Regel erst wahrgenommen, falls mehrere Bilder fehlen oder häufiger einzelne Bilder fehlen.
• Dagegen kann bereits der Ausfall einer Audio LDU vom Nutzer als störend wahrgenommen werden.
• Der Erfindung liegt daher die Aufgabe zugrunde, ein verbessertes Verfahren der gattungsgemäßen Art anzugeben, welches insbesondere zuverlässig ein für den Benutzer störungsfrei wahrnehmbares Ergebnis - Sprach- oder Musikausgabe oder Videosequenz - medienverarbeitender Prozesse liefert.
• Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst.
• Bei dem hier beschriebenen Ansatz soll medienverarbeitenden Prozessen die gleiche Leistung (Performance) eines ansonsten unbelasteten Rechners zur Verfügung gestellt werden. Das Konzept orientiert sich also nicht an der Einhaltung von Zeitvorgaben, sondern daran, die maximale Performanz zur Verfügung zu stellen.
• Für die bisher bekannten Lösungen war ein spezieller Scheduler notwendig, der den Zugriff auf die Ressource CPU steuert. Beim vorliegenden Ansatz wird der Zugriff auf die Ressource CPU nur durch bereits im System vorhandene Komponenten gesteuert, es ist jedoch zusätzlich eine neue Komponente notwendig, welche die Ressourcennutzung überwacht und bei Bedarf gezielt einschränken kann. Das neue Konzept wird durch drei Mechanismen realisiert:
  
• 1. Medienverarbeitende Prozesse werden gegenüber allen anderen Prozessen bevorzugt. Diesen stehen damit die gleichen CPU-Ressourcen zur Verfügung wie auf einem unbelasteten System. Diese Bevorzugung geschieht durch die Verwendung sehr hoher Prioritäten. Am besten geeignet ist der sogenannte Realtime-Modus, den die meisten Betriebssysteme anbieten.
• 2. Überwachung der CPU-Last medienverarbeitender Prozesse. Dies kann durch einfache Meßverfahren geschehen, welche meist bereits von den Betriebssystemen realisiert werden und lediglich geeignet abgerufen werden müssen.
• 3. Die CPU-Last medienverarbeitender Prozesse muß gezielt eingeschränkt werden können, falls ein gegebenes Limit überschritten wird. Dieser Mechanismus ist neu entwickelt worden und funktioniert, ohne den Zugriff auf die Ressource CPU direkt zu steuern.
• Ein wichtiger Aspekt bei der Realisierung dieses Mechanismus liegt darin, daß eine Einschränkung der Nutzung von CPU-Zeit im Allgemeinen nur durch den Prozeß-Scheduler erfolgen kann. Hier wird jedoch eine Eigenschaft medienverarbeitender Prozesse ausgenutzt, so daß eine spezielle Lösung für solche Prozesse gefunden werden kann. Diese haben die Eigenschaft, daß sie in mehr oder weniger gleichmäßigen zeitlichen Abständen LDUs verarbeiten müssen. Falls keine LDUs zur Verarbeitung vorhanden sind, zeigen solche Prozesse (unter bestimmten Voraussetzungen) keine Aktivität, d. h. sie benötigen die CPU Ressourcen nicht. Daher ist es grundsätzlich möglich, den Bedarf an CPU Ressourcen medienverarbeitender Prozesse zu senken, indem LDUs aus dem Datenstrom entfernt und verworfen werden. Diesen Effekt unter Verwendung geeigneter Steuerungsmechanismen auszunutzen, stellt eine neue Lösung des technischen Problems (Steuerung des CPU-Zeitbedarfs) für den Spezialfall medienverarbeitender Prozesse dar.
• Die Erfindung schließt zum einen das oben beschriebene neue Konzept ein, die von medienverarbeitenden Prozessen erzeugte CPU-Last indirekt über den Datenstrom zu steuern. Zum anderen gehören zur Erfindung neue Verfahren, welche die Regelung der CPU-Last durch die Steuerung des Datenflusses ermöglichen.
• Dabei werden betriebssystemeigene Meßverfahren der CPU-Last innerhalb eines Regelkreises verwendet, wie man ihn aus der Regelungstechnik kennt. Ein Software-Regler realisiert dabei eine der Standardregelungsfunktionen und bildet die Regelungsdifferenz auf einen Stellwert ab. Dieser Stellwert repräsentiert den Grad, in dem LDUs aus dem Datenstrom verworfen werden, also den Grad, in dem die CPU-Last ausgehend von ihrem Maximalwert gesenkt wird.
• Die Abbildung des Stellwertes der Strecke auf die Regelung des Datenflusses medienverarbeitender Prozesse stellt ein neues Verfahren dar. Dieses ist zudem aufgrund vieler Randbedingungen, die für den praktischen Einsatz notwendig oder zumindest hilfreich sind, nicht trivial. Folgende Randbedingungen werden von der Abbildung berücksichtigt:
  
• 1. Die Abbildung berücksichtigt bevorzugt Prozeßprioritäten. Verschiedene medienverarbeitende Prozesse sind für den Nutzer unterschiedlich wichtig, daher wird der Ressourcenverbrauch der einzelnen Prozesse unterschiedlich geregelt. Mit Hilfe einer Hauptpriorität wird eine feste Vorrangrelation zwischen Prozessen definiert. D. h. der Ressourcenverbrauch eines Prozesses mit hoher Priorität wird erst dann eingeschrankt, wenn der Ressourcenverbrauch aller Prozesse mit einer niedrigeren Priorität bereits maximal reduziert wurde. Beispiel: Bei einer Videokonferenz ist die Sprachübertragung deutlich wichtiger als die Bildübertragung, es ist also sinnvoll zunächst nur den Ressourcenverbrauch der Videoübertragung zu beschränken, bevor der Ressourcenverbrauch der Audioübertragung reduziert wird. Weiterhin kann mit Hilfe einer Sub-Priorität eine relative Gewichtung zwischen Prozessen gleicher Hauptpriorität definiert werden, so daß der Ressourcenverbrauch eines Prozesses starker beschrankt wird als der eines anderen.
• 2. Die Abbildung berücksichtigt insbesondere auch, daß der Datenfluß verschiedener medienverarbeitender Prozesse an unterschiedlichen Stellen des Verarbeitungsprozesses gesteuert werden muß.
• 3. Der Regler des Regelkreise erzielt i. d. R. die besten Ergebnisse, wenn das zu steuernde System linear auf Veränderungen des Aktuatorwertes reagiert. Dies ist jedoch im vorliegenden Anwendungsfall eher unwahrscheinlich. Die Abbildung verwendet daher insbesondere weitere Funktionen (Anpassungsfunktionen) als Parameter, die es bei Kenntnis des Prozeßverhaltens ermöglichen, eine lineares Verhalten anzunähern bzw. zu erreichen.
• 4. Die Abbildung kann zum einen dazu genutzt werden, den Grad zu bestimmen, in dem innerhalb der Verbindungen zwischen den StreamFiltern LDUs verworfen werden. Andererseits kann auch dem StreamFilter selbst die Stellwertinformation zugänglich gemacht werden, so daß dieser bei Regelungsbedarf einen weniger rechenzeitintensiven Algorithmus verwendet.
• Ein weiteres neues Verfahren ist der Notfall-Mechanismus, welcher in Fehlersituationen einem Prozeß die Real-Time Priorität entziehen kann und somit eine Blockade des gesamten Systems verhindert. Durch die Steuerung des Datenflusses kann die von einem Prozeß erzeugte CPU-Last gesteuert werden. Es sind jedoch Ausnahmesituationen denkbar, in denen dieser Steuerungsmechanismus nicht mehr funktioniert. So kann z. B. ein Prozeß aufgrund eines Programmierfehlers eine endlos lange Berechnung durchfuhren ("abstürzen").
• Der Verbrauch der Ressource CPU-Zeit ist dann nicht mehr abhängig von der Datenrate. Der Notfall-Mechanismus erkennt einen extrem hohen Ressourcenverbrauch und setzt daraufhin die Priorität des entsprechenden Prozesses auf ein normales Niveau zurück. Dadurch wird eine dauerhafte Blockade des gesamten Systems vermieden und der Nutzer kann eine geeignete Maßnahme zur Beseitigung des Fehlers einleiten.
• Die vorgeschlagene Lösung besitzt folgende Vorteile gegenüber der Verwendung von Schedulern oder Meta-Schedulern zur Berücksichtigung von Realzeit-Anforderungen:
  
• - Falls kein Regulierungsbedarf besteht - dies dürfte in vielen praktischen Fallen der Normalfall sein - wird nur ein geringer zusätzlicher Overhead (bzgl. der benötigten CPU- Zeit) erzeugt. Es muß lediglich der CPU-Zeit Bedarf einiger Prozesse überwacht werden anstatt den Zugriff auf die CPU ständig zu steuern.
• - Es wird nicht versucht, den Zugriff auf eine Ressource (die CPU) zu steuern, auf die Prozesse (normalerweise) keinen Zugriff haben. Kernelmodifikationen oder die Steuerung des sys-temeigenen Prozess-Scheduler über die Modifikation von Prioritäten sind nicht notwendig.
• - Falls aufgrund zu knapper Ressourcen Daten des Medienstromes verworfen werden müssen, kann dies an definierten und sinnvollen Stellen bzw. Zeitpunkten geschehen. So können z. B. bevorzugt Daten verworfen werden, die bisher nur wenige Verarbeitungsschritte durchlaufen haben. Daten, in die bereits viel CPU-Zeit "investiert" wurde können soweit wie möglich noch verarbeitet werden. Eine solche Unterscheidung ist bei der Verwendung von Schedulern nicht möglich, da die Scheduler keine Informationen über den Status der Datenverarbeitung eines Prozesses besitzen. Normalerweise werden Daten verworfen, sobald eine gegebene Deadline überschritten wurde. Falls Daten nach einer bestimmten Strategie verworfen werden sollen, muß dies durch zusätzliche Mechanismen geregelt werden.
• - Die Kenntnis von konkreten Realzeitanforderungen ist nicht erforderlich. Das Ziel ist lediglich die gleiche Performanz für die Medienverarbeitung zu erreichen, die auch auf einem System ohne zusätzliche non-realtime Prozesse erreicht wird. Scheduling Verfahren verfolgen dagegen das Ziel Daten bis zu einer gegebenen Deadline verarbeiten zu müssen, so daß zur Planung des Schedulings Zeitangaben wie Verarbeitungsdauer oder die Deadline notwendig sind. Die (unter Umständen schwierige) Feststellung solcher Parameter entfallt bei dem hier vorgestellten Ansatz.
• Vorteile und Zweckmäßigkeiten der Erfindung ergeben sich im übrigen aus den Unteransprüchen sowie der nachfolgenden Beschreibung eines bevorzugten Ausführungsbeispiels anhand der Figuren. Von diesen zeigen
• Fig. 1A bis 1D die wesentlichen Schritte einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens,
• Fig. 2 eine Prinzipdarstellung eines Regelkreises zum besseren Verständnis der beschriebenen Ausführungsform,
• Fig. 3 eine Prinzipdarstellung des sogenannten Stream-Konzeptes als Hilfsmittel zur Erläuterung der Erfindung,
• Fig. 4 eine grafische Darstellung einer einfachen Schar von Anpassungsfunktionen, die beim Schritt 2 des erfindungsgemäßen Verfahrens angewendet werden können,
• Fig. 5 eine Darstellung einer weiteren sinnvollen Anpassungsfunktionsschar, bei der ein weiterer sinnvoller Parameter eingeführt ist,
• Fig. 6 sechs weitere Beispiele für beim erfindungsgemäßen Verfahren anwendbare Anpassungsfunktionen,
• Fig. 7 eine weitere grafische Darstellung zur Verdeutlichung des Verlaufes einer Anpassungsfunktion für zwei Prioritäten und einen Schwellwert, wie sie bei dem erfindungsgemäßen Verfahren Anwendung finden kann, und
• Fig. 8A bis 8D eine den Fig. 1A bis 1D entsprechende Darstellung einer Ausführungsform des erfindungsgemäßen Verfahrens, wobei der globale Stellwert in den Bereich der zweiten Prioritätsklasse abgefallen ist.
• In Fig. 1A bis 1D ist dargestellt, wie der globale Stellwert in mehreren Schritten auf ein Maß zum Verwerfen von LDUs abgebildet wird, das dann in einer konkreten Verbindung zweier StreamFilter angewendet wird:
  Schritt 1 (Fig. 1A): Abbildung des globalen Actuators auf den Actuator einer Prozeßklasse. Hierfür wird der Wertebereich des globalen Actuators entsprechend der vorhandenen Hauptprioritäten der Prozesse in Klassen unterteilt. Anschließend wird anhand des aktuellen Wertes des globalen Actuators eine Klasse bestimmt. Nur die Prozesse, die dieser Klasse angehören werden geregelt. Prozesse, die einer Klasse niedrigerer Priorität angehören werden vollständig angehalten. Prozesse, die einer Klasse höherer Priorität angehören laufen ohne Beschränkung des Ressourcenverbrauchs.
• Fig. 1A zeigt beispielhaft einen partitionierten Hauptstellwert, der in 4 Partitionen aufgeteilt wurde. Im Beispiel existieren 4 Prioritätsklassen, mit 4 unterschiedlichen Hauptprioritäten, bei insgesamt 10 Streams. Innerhalb der Prioritätsklasse mit der niedrigsten Priorität laufen 3 Streams - die Prioritätsklasse befindet sich am oberen Ende der linken Säule. Die Position des globalen Stellwerts wird auf die aktuelle Partition umgerechnet. So ergibt sich der Stellwert der Prioritätsklasse (0 . . . 1000). Wechselt der globale Stellwert in eine Prioritätsklasse mit hoherer Priorität, so sind alle Streams der jeweils niedrigeren komplett abgeschaltet.
• Innerhalb einer Prioritätsklasse können mehrere Streams mit jeweils unterschiedlichen Subprioritäten laufen. Aus dem Stellwert der Prioritätsklasse wird ein Stellwert für den jeweiligen Stream generiert (0 . . . 1000). Dazu werden verschiedene Anpassungsfunktionen eingeführt, die diese Umsetzung unterschiedlich vornehmen können. Gemeinsam ist allen Anpassungsfunktionen der Kurvenscharparameter P, der die Subpriorität darstellt.
• Schritt 2 (Fig. 1B): Abbildung des Actuators einer Prozeßklasse auf Actuatoren für einzelne Prozesse (= Streams). Mit Hilfe einer Adaptionsfunktion wird für jeden Stream der Klasse der Actuator der Prozeßklasse auf den jeweiligen Stream-Actuator abgebildet. Die Adaptionsfunktion ist dabei abhängig von der Subpriorität des jeweiligen Streams.
• Schritt 3 (Fig. 1C): Abbildung des Stream-Actuators auf die einzelnen Connection-Actuatoren. Jedes Verbindungsobjekt besitzt eine Priorität. Es wird das gleiche Verfahren wie im Schritt 2 beschrieben verwendet, um den Stream-Actuator auf die jeweiligen Connection-Actuatoren abzubilden.
• Schritt 4 (Fig. 1D): Verwerfen von Daten in Abhängigkeit des Connection-Actuators. Da immer nur ganze LDUs verworfen werden können, wird ein Zähler bestimmt der festlegt, wie oft eine LDU aus dem Datenstrom entfernt wird. Bei der Bestimmung des Zahlers werden nicht nur ganzzahlige Werte berücksichtigt. Es ist z. B. möglich abwechselnd jede 3te bzw. jede 4te LDU zu verwerfen, dies entspricht dem Verwerfen jeder 3,5ten LDU. Weiterhin werden Änderungen des Connection- Actuators so auf den Zählerwert übertragen, daß ein neuer Actuatorwert nicht den Neustart des Zählvorganges erfordert. Damit ist es möglich regelmäßig neue Actuatorwerte zu bestimmen ohne dadurch die Regelung zu beeinflussen.
• Zusätzlich zum Verwerfen von LDUs ist es auch möglich, den Stream-Actuator allen StreamFiltern zugänglich zu machen, damit diese ihren Verarbeitungsalgorithmus anpassen mit dem Ziel weniger CPU-Ressourcen zu belegen.
• Fig. 1B bis 1D zeigen die Schritte 2 bis 4 jeweils für die niedrigsten Prioritäten (1000), eine quadratische Stream-Anpassungsfunktion, eine lineare Verbindungs-Anpassungsfunktion und einen Schwellwert von 0.
• Weiter unten wird eine detaillierte Beschreibung zur Ausführung dieser Schritte gegeben. Die beschriebenen Verfahren wurden in einem Prototyp implementiert und sind unter Windows NT lauffähig.
• Falls ein Prozeß nicht mehr über den Datenfluß gesteuert werden kann, z. B. weil dieser Prozeß "abgestürzt" ist, muß ein Notfall-Mechanismus greifen, der einen solchen Prozeß auf eine normale Prioritätsstufe zurückversetzt. Andernfalls könnte ein solcher Prozeß das gesamte System blockieren. Dazu wird überwacht, ob die Gesamtheit der medienverarbeitenden Prozesse einen bestimmten Schwellwert für die CPU-Last für einen "längeren" Zeitraum (z. B. 1 Sekunde) überschreitet. Dieser Schwellwert muß deutlich höher liegen als der Schwellwert, bei dem der oben beschriebene Regelungsprozeß einsetzt. Alternativ kann auch ein wesentlich längerer Zeitraum betrachtet werden. Im dem Fall, daß der Notfall- Mechanismus greift, wird folgendes Verfahren angewendet:
  Schritt N1: Wähle den medienverarbeitenden Prozeß aus, welcher die meiste CPU-Last erzeugt;
  Schritt N2: Setze diesen Prozeß auf eine normale Priorität zurück;
  Schritt N3: Verfahre weiter mit Schritt N1, wenn die CPU-Last der verbleibenden medienverarbeitenden Prozesse (im Realtime Modus) noch oberhalb des Schwellwertes für das Eingreifen des Regelungsmechanismus liegt.
• Dieser Mechanismus ist generell dazu geeignet, Überlastsituationen zu beheben, welche durch den Regelungsmechanismus nicht oder nur schlecht kontrolliert werden können. In speziellen Situationen ist es auch denkbar, ausschließlich diesen Mechanismus zu verwenden, wenn davon ausgegangen werden kann, daß eine Regelung des Datenflusses niemals nötig ist, aufgrund der niedrigen erwarteten CPU- Last. Soll z. B. lediglich ein Audiostrom verarbeitet werden, so liegt die dafür erforderliche CPU-Last auf heutigen Desktop-Systemen üblicherweise deutlich unter 10%. Eine Regelung der CPU-Last über den Datenfluß wird also voraussichtlich niemals nötig sein. Bei einer dauerhaften Überschreitung der CPU-Last von z. B. 40% kann von einer Fehlfunktion ausgegangen werden und der Prozeß zur Verarbeitung des Audiostromes auf eine normale Priorität zurückgestuft werden.
• Fig. 2 und 3 zeigen zum besseren Verständnis der Erfindung eine Skizze zur Darstellung eines Regelkreises bzw. des sogenannten Stream-Konzeptes zur Verarbeitung von Mediendatenströmen.
• Der Regelkreis besteht im Wesentlichen aus dem Regler, einer (Regel-)Strecke und einem Meßverfahren. Mit Hilfe eines geeigneten Meßverfahrens wird regelmäßig der Zustand des zu steuernden Systeme festgestellt und als Ist-Wert x(t) für den Regelkreis zur Verfügung gestellt. Dem Regelkreis wird ein Sollwert w(t) vorgegeben und mit dem Ist-Wert x(t) verglichen, deren Differenz x_d(t) dient periodisch als Eingabewert für den Regler. Der Regler berechnet daraufhin einen neuen Stellwert y(t) für die Strecke. Dieses Prinzip ist bekannt und stammt aus der Regelungstechnik, ebenso wie Berechnungsverfahren für den Regler. Ebenfalls bekannt ist das hier verwendete Meßverfahren. Neu ist hier das Anwendungsgebiet dieses Regelungsverfahrens, sowie die Abbildung des Stellwertes der Strecke (auch Actuatorwert) auf die Steuerung des Datenflusses medienverarbeitender Prozesse.
• Die Verarbeitung von Medienströmen (also Ströme von Logical Data Units = LDUs) wird üblicherweise nach dem sogenannten Stream-Konzept durchgeführt (siehe Fig. 3). Die Verarbeitungsschritte werden von einzelnen Stream-Filtern realisiert. Diese werden über Verbindungsobjekte je nach Bedarf miteinander verbunden, so daß ein Verarbeitungsprozeß entsteht, welcher dann auch als Stream bezeichnet wird. Dieser kann eine Folge sequentieller Ablaufe sein, aber auch komplexere Formen annehmen. Die Arbeit des Streams wird von einem Stream-Manager gesteuert. Eine Anwendung kommuniziert lediglich mit diesem Manager und steuert über Kommandos (z. B. Start, Stop, Pause, . . .) den Stream. Ein solcher Stream ist dann nicht mehr notwendigerweise ein Teil der Applikation, sondern kann als eigenständiger Prozeß laufen.
• Das Ziel dieser Abbildung ist es anhand eines globalen Stellwertes den Ressourcenverbrauch verschiedener Prozesse zu regulieren. Die Regulierung geschieht durch das Verwerfen von sogenannten Logical Data Units (LDU).
• Der globale Stellwert kann Werte innerhalb eines bestimmten Intervalls (0 . . . 10000) annehmen. Wird das Maximum erreicht, werden im gesamten System keine LDUs verworfen. Wird 0 erreicht, sind alle Streams des Systems abgeschaltet.
• Streams erhalten zwei Prioritäten - die Hauptpriorität (0 . . . 1000) und die Subpriorität (0 . . . 1000). Je kleiner der Zahlenwert ist, desto hoher ist die Priorität. Die Hauptpriorität unterteilt die Streams in Klassen, wahrend die Subpriorität innerhalb dieser Klassen für eine Rangfolge sorgt. Die Prioritätsklasse mit der niedrigsten Hauptpriorität (höchster Wert) wird als erste zur Regelung herangezogen. Dazu wird das Intervall des Hauptstellwertes analog zu der Zahl der Prioritätsklassen partitioniert, gewichtet nach der Anzahl der Streams in jeder Klasse.
• Fig. 4 zeigt die einfachste Anpassungsfunktionsschar, basierend auf einer linearen Funktion. P steuert, ab welchem Wert der Stream-Stellwert (SA), ausgehend vom Maximalwert, beginnt, mit linearem Verlauf abzusinken, bis mit dem 0- Durch-gang des Prioritätsklassen-Stellwerts (PCA) für alle Anpassungsfunktionen ebenfalls der Wert 0 erreicht wird. Bei einem Prioritätswert von 0 wird an diesen Stream immer nur der Maximalwert (1000) für den Stream-Stellwert weitergegeben:
  In Fig. 5 wird ein weiterer sinnvoller Parameter verdeutlicht, nämlich ein Schwellwert für den Stream- Stellwert, der nicht unterschritten werden darf. Wird der Prioritätsklassen-Stellwert so klein, daß nach der Adaptionsfunktion der Schwellwert für den Stream unterschritten wurde, schaltet der Stream ab. Durch die frühzeitige Abschaltung eines Streams wird vermieden, daß ein Medium mit extrem schlechter Qualität dargestellt wird. Dies dürfte i. d. R. als störender empfunden werden als ein nicht vorhandener Datenstrom.
• Sinnvoll ist in diesem Zusammenhang auch die Anwendung einer Hystereseeigenschaft, damit nach dem Abschalten eines Streams dieser nicht sofort wieder aktiviert wird und auf diese Weise ein Schwingen des Regelkreises erzeugt.
• Fig. 6 zeigt sechs weitere Anpassungsfunktionen, die in der ersten Realisierung zur Verfügung stehen. jeweils mit dem Verlauf der Anpassungsfunktion für zwei Prioritäten und einem Schwellwert von 0. Die Möglichkeit unterschiedlicher Funktionen Adaptionsfunktionen zu verwenden, soll es erleichtern, ein lineares Verhalten der Regelstrecke zu erreichen. Im Folgenden sind die Funktionsgleichungen aufgeführt: 1) Logarithmische Anpassungsfunktion
  
  2) Quadratische Anpassungsfunktion
  
  3) Sinusförmige Anpassungsfunktion
  
  4) Polynomiale Anpassungsfunktion
  
  5) Quadratische Anpassungsfunktion
  
  6) Exponentielle Anpassungsfunktion
  
  
• Ist ein Schwellwert definiert, so wird das Ergebnis für SA auf 0 gesetzt, wenn der berechnete Wert den Schwellwert unterschreitet. Ist der Prioritätswert 0 (höchste Priorität), so wird SA immer der maximale Stellwert (1000) zugeordnet.
• Damit weitere Nichtlinearitäten der Strecke untersucht werden können, gibt es für Streams eine weitere Anpassungsfunktion, die der Strecke eine Hystereseeigenschaft verleiht, wenn ein Schwellwert definiert wird. Fig. 7 zeigt den Verlauf der Anpassungsfunktion für zwei Prioritäten und einen Schwellwert. Hier ist es von der Vorgeschichte abhängig, welcher Wert als Stream-Stellwert zurückgegeben wird. Der nichtlineare Sprung findet bei unterschiedlichen Prioritätsklassen-Stellwerten statt, je nachdem, ob der Stream ein- oder abgeschaltet wird. Auch im eingeschalteten Zustand wird der zurückgelieferte Wert von zwei unterschiedlichen linearen Funktionen nach unten und oben begrenzt.
• Der auf die Streams verteilte globale Stellwert wird nun innerhalb des Streams auf die Verbindungs-Objekte umgebrochen. Die Verbindungen erhalten bei ihrer Erzeugung eine Priorität (0 . . . 1000), die sie gegenüber anderen Verbindungen desselben Streams gewichtet. Die für Streams verwendeten Anpassungsfunktionen werden auf Verbindungsebene erneut genutzt, um aus dem Stream-Stellwert einen prioritätsabhängigen Verbindungsstellwert zu berechnen. Jedoch wird hier auf den Mindeststellwert verzichtet.
• Fällt der globale Stellwert bei dem in Fig. 1A bis 1D skizzierten Verfahren so weit ab, daß er in den Bereich der zweiten Prioritätsklasse fällt, so garantiert das System, daß alle Streams der darüberliegenden Partition abgeschaltet werden und nun innerhalb der zweiten Partition derselbe Mechanismus greifen kann, wie schon vorher für die erste. Diese Situation ist in Fig. 8A bis 8D dargestellt.
• Schließlich müssen noch Daten in Abhängigkeit des Connection- Actuators verworfen werden. Aus dem Wert des Connection- Actuators wird ein reeller Zähler bestimmt. Für jede Dateneinheit, die ein Verbindungsobjekt durchlauft, wird dieser Zähler um 1 verringert. Fällt dabei der Zählerwert unter den ganzzahligen Wert 1, so wird die aktuelle Dateneinheit verworfen. Anschließend wird der Rest des Zahlers auf den initialen Zählerwert addiert. Auf diese Weise können nicht ganzzahlige Zählerwerte berücksichtigt werden. Wenn der Connection-Actuator verändert wird, dann wird ein neuer initialer Zählerwert berechnet, der aktuelle Zählerwert bleibt erhalten, falls dieser niedriger ist als der neue initiale Wert. Andernfalls wird der aktuelle Zahler auf den neuen initialen Zählerwert gesetzt.
• Die Ausführung der Erfindung ist nicht auf das oben beschriebene Ausführungsbeispiel und die alternativ gezeigten Anpassungsfunktionen beschränkt, sondern ebenso in einer Vielzahl von Abwandlungen - insbesondere mit weiteren Anpassungsfunktionen und beliebigen Prioritäten- Konstellationen - möglich.

Claims (8)

1. Verfahren zur Steuerung der Abarbeitung medienverarbeitender Prozesse auf einem Datenprozessor oder einer zusammenwirkenden Datenprozessorgruppe, wobei die medienverarbeitenden Prozesse miteinander und/oder mit anderen Prozessen konkurrieren, dadurch gekennzeichnet, daß
dem oder jedem medienverarbeitenden Prozeß eine Prioritätsstufe einer vorbestimmten Skala von Prioritätsstufen zugewiesen wird, wobei gegenüber anderen Prozessen höhere Prioritäten vergeben werden,
die prioritätshöchsten Prozesse ohne vorab festgelegtes Zeitlimit bevorzugt abgearbeitet werden,
die Prozessorlast, insbesondere der Verarbeitungszeitbedarf, infolge des medienverarbeitenden Prozesses bzw. der medienverarbeitenden Prozesse, spezifisch bestimmt und überwacht wird und
die Prozessorlast des medienverarbeitenden Prozesses bzw. der medienverarbeitenden Prozesse eingeschränkt wird, wenn sie einen ersten vorbestimmten Grenzwert überschreitet.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß eine Einschränkung der Prozessorlast durch Entfernen und Verwerfen von Dateneinheiten eines Mediendatenstromes oder eine Variation des verwendeten Verarbeitungsalgorithmusses in den Verarbeitungseinheiten ausgeführt wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Prozessorlast durch mehrere auf dem Prozessor bzw. der Prozessorgruppe laufende medienverarbeitende Prozesse, falls eine Einschränkung erforderlich wird, differenziert in Abhängigkeit von der Prioritätsstufe der medienverarbeitenden Prozesse eingeschränkt wird.

4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Zuweisung einer Prioritätsstufe auf zwei Ebenen als Zuweisung einer Haupt- und einer Subpriorität ausgeführt wird.

5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß im Ergebnis der Überwachung der Prozessorlast und eines Vergleiches mit einem zweiten, wesentlich oberhalb des ersten Grenzwertes liegenden Grenzwert eine Herabsetzung der Prioritätsstufe eines mit extrem hoher Prozessorlast ablaufenden medienverarbeitenden Prozesses vorgenommen wird.

6. Verfahren nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, daß für ein etwaiges Entfernen und Verwerfen von Dateneinheiten eines Mediendatenstromes definierte Verarbeitungspunkte vorbestimmt werden und während der Abarbeitung des medienverarbeitenden Prozesses ein Entfernen dort ausgeführt wird.

7. Verfahren nach einem der Ansprüche 2 bis 6, dadurch gekennzeichnet, daß für ein etwaiges Entfernen und Verwerfen von Dateneinheiten eines Mediendatenstromes eine definierte Strategie vorbestimmt und während der Abarbeitung des medienverarbeitenden Prozesses realisiert wird.

8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß ein Standardverfahren der Regelungstechnik verwendet wird, um die automatische Anpassung der CPU-Last von medienverarbeitenden Prozessen an einen vorbestimmten Sollwert zu erreichen.