DE69127945T2

DE69127945T2 - Ablauffolgeplanungsmethode für Multiprozessorbetriebssystem

Info

Publication number: DE69127945T2
Application number: DE69127945T
Authority: DE
Inventors: Mark A Borcherding; J Charles Kuhlman; Steve Schneider
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 1990-08-31
Filing date: 1991-08-30
Publication date: 1998-02-12
Anticipated expiration: 2011-08-31
Also published as: EP0473444B1; DE69127945D1; EP0473444A3; JP3676827B2; EP0473444A2; JPH06119300A; US5303369A

Description

[Technisches Gebiet der Erfindung]

Diese Erfindung bezieht sich auf Computersysteme und insbesondere auf ein Verfahren für die Ablaufsteuerung von Tasks eines Multiprozessor-Multitasking-Systems.

[Hintergrund der Erfindung]

Die Mehrfachverarbeitung ist ein Typ der parallelen Verarbeitung, die die Ausführung separater Programme auf zwei oder mehr Prozessoren aufteilt. Multitasking ist ein Spezialfall der Mehrfachverarbeitung, die einen Softwareprozeß, d. h. eine Task, als ein Unterprogramm definiert, das gleichzeitig mit anderen Unterprogrammen ausgeführt werden kann.
In einer Multitasking-Umgebung müssen die Tasks und Datenstrukturen eines Arbeitsauftrags gewissenhaft aufgeteilt werden, um die parallele Ausführung ohne Konflikte zu ermöglichen. Jedoch sind die Verfügbarkeit der Prozessoren, die Reihenfolge der Ausführung und der Abschluß der Tasks Funktionen der Laufzeitbedingungen des Systems. Daher ist Multitasking inhärent nicht deterministisch bezüglich der Zeit, obwohl die Tasks ihrerseits wohl definiert sein können.
Um ein erfolgreiches Multitasking sicherzustellen, muß nach dem Aufteilen der Tasks ein Betriebssystem entwickelt werden, das eine effiziente gemeinsame Nutzung der Betriebsmittel sicherstellt. Die Zuweisung der Betriebsmittel zu den Prozessen wird als "Ablaufsteuerung" bezeichnet. Die Ablaufsteuerung ist insbesondere in Systemen wichtig, die eine Echtzeitantwort auf Echtzeiteingaben erfordern.
Die meisten bestehenden Multitasking-Ablaufsteuerungssysteme verwenden ein Prioritätssystem, das in seiner Eigenschaft statisch ist. Das Prioritätssystem berücksichtigt nicht die Verarbeitungsanforderungen einer Task wie z. B. die Frage, wie lange die Task dauern sollte, wieviel Speicher sie erfordert oder deren Speicheranforderungen im Zeitverlauf. Die letzte Anforderung wird dadurch bestimmt, wie lang die Task bei Verwendung einer gegebenen Menge an Speicher ausgeführt werden kann, bevor sie mehr Speicher benötigt.
Ein weiterer Lösungsansatz für die Ablaufsteuerung verwendet die "Zeitscheibentechnik", in der Abschnitten einer Task eine begrenzte Zeitspanne zur Verfügung gestellt wird, in der diese ausgeführt werden. Nach dieser Zeitspanne wird ein Abschnitt einerweiteren Task ausgeführt. Wenn somit eine Task in ihrer Zeitspanne nicht fertig wird, wird der Prozes sor an die nächste wartende Task vergeben und die nicht beendete Task wird zurückgestellt. Der Nachteil des Zeitscheibenlösungsansatzes ist die Organisation der Kontextumschaltung.
Es besteht Bedarf an einer Vorrichtung für die Zeitablaufsteuerung von Tasks, so daß die Betriebsmittel ohne Erzeugung einer zusätzlichen Verarbeitungsorganisation effizient genutzt werden.
Die EP-A-0 346 039 bezieht sich auf ein Multi-Benutzer-Computersystem, das eine Zentraleinheit (CPU), ein Betriebssystem mit seitenadressiertem virtuellen Speicher sowie einer Systemspeicherstelle zum Speichern eines festen Satzes von Systembetriebsparametern mit im voraus zugewiesenen Steuerwerten für die Zuweisung des Zugriffs auf die Systembetriebsmittel verwendet. Die Betriebsmittel umfassen CPU-Verarbeitungszyklen und residenten Speicher, wobei eine oder mehrere Meßvorrichtungen und Überwachungsroutinen verwendet werden, um Werte für einen Satz von gemessenen Leistungsparametern für jeden Prozeß bezüglich seiner Zuweisung der Systembetriebsmittel zu erzeugen.
Es werden ein Verfahren und eine Vorrichtung offenbart zum dynamischen Neuzuweisen der Systembetriebsmittel, die umfassen: das Schaffen eines vordefinierten Satzes gewünschter Leistungswerte in einer Speicherstelle, das Aufzeichnen der laufenden gemessenen Systemleistungswerte für jeden Prozeß in einer zweiten Speicherstelle, das Erzeugen von Anpassungsfaktoren gemäß einer vorgegebenen Beziehung für die jeweils entsprechenden gemessenen und gewünschten Leistungswerte und das Einstellen der Systembetriebsparameter entsprechend diesen Einstellungsfaktoren.
Ein Verfahren zum dynamischen Anpassen der Systembetriebsparameter in einem Multi-Benutzer-Computersystem als Antwort auf Veränderungen der Belastung des Systems durch separate Prozesse, die auf dem System laufen, ist auf einem Multi- Benutzer-Computersystem implementiert, das eine Zentraleinheit (CPU), einen seitenadressierten virtuellen Speicher und einen Satz vordefinierter Systemsteuerparameter verwendet, die mit einem entsprechenden Satz von Steuerwerten zum Zuweisen des Zugriffs auf die Systembetriebsmittel durch den jeweiligen Prozeß kombiniert sind. Die Betriebsmittel umfassen CPU-Verarbeitungszyklen, die Arbeitseinstellungsspeichergröße und die Verarbeitungszeit, die Prozeßpriorität sowie die E/A-Übertragungszeitsteuerung, wobei eine oder mehrere Überwachungsroutinen zum Messen einer Reihe interner Leistungswerte für jeden Prozeß bezüglich seiner Zuweisung an Systembetriebsmitteln vorhanden sind. Das Verfahren der dynamischen Neuzuweisung von Systembetriebsmitteln durch Anpassen der vordefinierten Systemsteuerparameter umfaßt die Schritte des Speicherns eines Satzes gewünschter Leistungswerte in einer Speicherstelle, des Akkumulierens der gemessenen überwachten Leistungswerte als Antwort auf die laufenden Systemsteuerparameter für jeden Prozeß in einer zweiten Speicherstelle, des Erzeugens von Anpassungsfaktoren gemäß einer vorgegebenen Beziehung zwischen den entsprechenden gemessenen und gewünschten Leistungswerten sowie des Anpassens der Systemsteuerparameter als Antwort auf die Einstellungsfaktoren.
Die Druckschrift PROCEEDINGS A.F.I.P.S. NATIONAL COMPUTER CONFERENCE, Bd. 44, 19. Mai 1975, Anaheim, USA, S. 343-350, J. C. Strauss, "Dynamic dispatching in job dass scheduled systems", stellt in seiner Referenz 2 fest, daß Wulf mögliche Probleme der Zeitablaufsteuerung aufgrund geringen Vorwissens der Jobeigenschaften vermeidet, indem er die Ausführung einzelner Jobs auf der Grundlage der gemessenen Nutzung der Systembetriebsmittel durch die Jobs dynamisch steuert. Die Druckschrift nimmt Bezug auf einen Systemsteuermechanismus, der die Spezifizierung der eindeutigen internen preemptiven CPU-Priorität verwendet, die einer einzelnen Task von jeder von mehreren Klassen über ein Steuerintervall verliehen wird. Diese Priorität wird spezifiziert auf der Grundlage der beobachteten Leistung des Systems. Die Spezifikation der geordneten Prioritäten der Klassen wird als Prioritätsabbildung bezeichnet. Das Systemverhalten wird über die Job-CPU-Nutzung beobachtet, die für eine Task aus der i-ten Jobklasse erreicht wird, wenn sie in einer Prioritätsabbildung j mehrfachverarbeitet wird.
Es wird festgestellt, daß in einem Normsystem mit eingeteilten OS/360-Jobklassen keine dynamische Abfertigung vorliegt. Es besteht eine feste Beziehung zwischen den Jobklassen und der preemptiven CPU-Abfertigungspriorität der Tasks von den Jobs in dieser Klasse (bis zu dem Ausmaß, daß die Abfertigungspriorität mit der Partition oder dem Bereich einhergeht und mehrere Klassen dieselbe Partition oder denselben Bereich speisen können).
Die vorliegende Erfindung schafft ein Verfahren für die Ablaufsteuerung von Tasks, die von Prozessoren eines Multitasking-Multiprozessorsystems auszuführen sind, mit den folgenden Schritten:
Ausführen eines Anwendungsprogramms, das die Abarbeitung mehrerer Tasks in einer besonderen Reihenfolge erfor dert;
Bestimmen der Verarbeitungseigenschaften der mehreren auszuführenden Tasks;
Herstellen einer Beziehung zwischen den Tasks und einer Datenstruktur, die die Verarbeitungseigenschaften repräsentiert;
Anordnen der mehreren Tasks in einer Task-Warteschlange;
Ausgliedern einer ersten Task der mehreren auf die Abarbeitung wartenden Tasks aus der Warteschlange;
Beanspruchen der Verarbeitungseigenschaften der ersten Task in einem Zeitablaufsteuerprogramm;
Auswählen von für die erste Task zu verwendenden Verarbeitungsbetriebsmitteln als Antwort auf die Verarbeitungseigenschaften und verfügbare Betriebsmittel unter Verwendung des Zeitablaufsteuerprogramms; und
Aktivieren eines Alarmtreibers, wenn die erste Task die Verarbeitungsbetriebsmittel zu nutzen beginnt, und Ausführen einer Zeitsteuerung der Nutzung, um tatsächliche Verarbeitungseigenschaften zu erzeugen;
Aktivieren eines Überzeit-Managers, falls die tatsächlichen Verarbeitungseigenschaften einen vorgegebenen Wert übersteigen, wobei der Überzeit-Manager die Abarbeitung der Task anhält, einen Verarbeitungsstatus der ersten Task diagnostiziert, um festzustellen, ob ein Problem eine Verzöge rung verursacht, und, falls ja, bestimmt, wie die Verzögerung zu lösen ist, und bestimmt, ob die Verarbeitungseigenschaften inkorrekt sind; und
Wiederholen des Schrittes des Ausgliederns einer Task aus der Warteschlange, des Beanspruchens der Verarbeitungseigenschaften, des Auswählens von Verarbeitungsbetriebsmitteln und des Aktivierens des Alarmtreibers und gegebenen- falls des Überzeit-Managers, bis sämtliche Tasks abgearbeitet worden sind.
Ein technischer Vorteil der Erfindung besteht darin, daß leichter eine Echtzeitantwort erreicht werden kann. Die Tasks werden entsprechend ihrer Verarbeitungsanforderungen eingeteilt, mit dem Ziel, der Task zu ermöglichen, so lange zu laufen, wie sie benötigt. Die Leistung eines Systems kann ebenfalls überwacht werden, um zu ermitteln, wie dessen Betriebsmittel belastet sind und ob es eine zusätzliche Verarbeitung unterstützen kann.

[Kurzbeschreibung der Zeichnungen]

Fig. 1 ist ein Blockschaltbild eines Multiprozessor- Multitasking-Computerverarbeitungssystems mit einem Host-Prozessorsystem in Verbindung mit einem Signalprozessorsystem.
Fig. 2 ist ein Blockschaltbild, das eine typische Anwendung des Multiprozessorsystems der Fig. 1 zeigt, die zur Verarbeitung von Fernsprechverbindungen verwendet wird.
Fig. 3 ist ein funktionelles Blockschaltbild des Programmund Datenspeichers der Signalprozessoren der Fig. 1.
Fig. 4 ist ein Diagramm für die Programmierung des Ablaufsteuerungssystems für die jeweiligen Signalprozessoren der Fig. 1.

[Genaue Beschreibung der Erfindung]

Fig. 1 ist ein Blockschaltbild eines Multiprozessor-Multitasking-Computerverarbeitungssystems mit einem Host-Prozessorsystem 11 in Verbindung mit einem Signalprozessorsystem 15. Die Kommunikationseinrichtung zwischen den Prozessoren 11 und 15 ist eine Busleitung 19, die irgendeiner von mehreren bekannten Normen für die binäre Kommunikation entspricht, wie z. B. der 32-Bit-Nubus-Norm. Ein Vorteil der Erfindung besteht darin, daß sie mit der einfachen Speicherabbildungsarchitektur der Nubus-Norn kompatibel ist.
Das Host-Prozessorsystem 11 enthält einen Host-Prozessor 12 und einen Speicher 13. Der Host-Prozessor ist typischerweise ein Universalprozessor, wie z. B. der von der Motorola Corporation hergestellte 68030. Der Speicher 13 enthält einen Programmspeicher zum Speichern von Befehlen für den Host- Prozessor 12 sowie einen Speicher zum Speichern der Programmroutinen und Parameter, die zum Signalprozessorsystem 15 heruntergeladen werden sollen. Der Herunterladeprozeß wird im folgenden genauer erläutert.
Das Signalprozessorsystem 15 enthält mehrere Signalprozessoren 16 und einen Speicher 17, der diesem jeweils zugeordnet ist. Ein Beispiel eines Signalprozessors 16 ist der TMS 320C30, der von Texas Instruments Inc. hergestellt wird. Eine geeignete Größe für den Speicher 17 für die hier beschriebene Anwendung beträgt 250k 4 Bytes. Das Signalprozessorsystem 15 führt Programmroutinen aus, die vom Host-Prözessor 12 heruntergeladen worden sind. Wenn die Ausführung einer Programmroutine abgeschlossen ist, benachrichtigt das Signalprozessorsystem 15 den Host-Prozessor 12, so daß der Host-Prozessor 12 eine weitere Routine herunterladen kann.
Die Signalprozessoren 16 stehen untereinander in Verbindung, was dem Signalprozessorsystem 15 ermöglicht, mehr als eine Task gleichzeitig auszuführen. Zum Beispiel kann das Signalprozessorsystem drei Signalprozessoren 16 umfassen, wie in Fig. 5 gezeigt ist. Jeder Signalprozessor 16 besitzt seinen eigenen Speicher 17, der mit einem benachbarten Speicher 17 kreuzgekoppelt ist, um eine Kommunikation zwischen den Signalprozessoren 16 zu ermöglichen.
Jeder Signalprozessor 16 besitzt einen Aufrufbehandler, so daß mehr als ein ankommender Aufruf gleichzeitig verarbeitet werden kann. Die Verarbeitung kann sich für jeden Aufruf in Abhängigkeit von den Skripten ändern, die vom Host-Prozessor 12 geliefert werden.
Fig. 2 zeigt eine typische Anwendung des Multiprozessorsystems 10, die für die Verarbeitung von Fernsprechverbindungen verwendet wird. Bei dieser Anwendung ist das Host-Prozessorsystem 11 Teil eines Dienststeuersystems 21, das einen Sprachnachrichtendienst handhabt. Das Dienststeuersystem 21 besitzt ferner einen Kommunikationsträger und geeignete Schnittstellen für die Kommunikation mit einem (nicht gezeigten) Datenbankmanagementsystem, das Kundenaufzeichnungen und andere Informationen hält, die ein großes Datenbanksystem erfordern. Das Dienststeuersystem 21 steht ferner über den Bus 19 mit einem Telephoniesteuersystem 22 in Verbindung, das das Digitalverarbeitungssystem 15 enthält. Über einen T1- Puffer 23 empfängt das Digitalverarbeitungssystem 15 Daten von einer T1-Leitung 24 und führt das aktuelle Senden und Empfangen von Sprachdaten gemäß den Telekommunikationsprotokollen aus. Ein Beispiel eines T1-Puffers 23 ist die ST-Bus- Parallelzugriffsschaltung Mitel MT8920. Wie im folgenden in Verbindung mit Fig. 3 erläutert wird, ist in praktischen Anwendungen der Erfindung das Signalverarbeitungssystem 15 ein Multiprozessor-Multitasking-System mit mehreren Signalprozessoren 16, das Eingaben von mehreren Kanälen der T1- Leitung empfängt.
Eine vollständigere Beschreibung der Verwendung des Multiprozessorsystems 10 für eine Sprachnachrichtenanwendung ist in der EP-A-0 472 386 mit dem Titel "Digital Signal Processing Control Method and Apparatusyv dargestellt, die ebenfalls dem Anmelder der vorliegenden Erfindung zugeteilt ist. Das hier beschriebene Verfahren ist ein Verfahren der Übertragung von Daten innerhalb der Multiprozessorumgebung dieser Erfindung.
Das Verfahren der vorliegenden Erfindung ist jedoch nicht auf die Operation mit dieser speziellen Konfiguration beschränkt, und kann wie in Fig. 1 gezeigt mit einer beliebigen Multiprozessorumgebung verwendet werden, in der wenigstens zwei Prozessoren gemeinsam auf den Speicher eines Prozessors zugreifen.
Die Verarbeitung der Tasks des Signalverarbeitungssystems 15, d. h. die vom Signalprozessor 16 auszuführenden Funktionen, werden von Abschnitten eines Anwendungsprogramms dargestellt, das in das Host-Prozessorsystem 11 geladen worden ist. Diese Abschnitte des Codes werden hier als "Skripten" bezeichnet. Der Host-Prozessor 12 ermittelt dynamisch die spezifische Reihenfolge der auszuführenden Tasks und ermittelt somit das "Skript". Das Skript wird in einer Pseudocode-Form zum Signalprozessor 12 heruntergeladen und von einem Skript-Interpreter 32, der in Fig. 3 gezeigt ist, interpretiert. Das Ergebnis ist ein Satz von Byte-Codes, die Tasks spezifizieren, für die der Host-Prozessor 12 einen Signalprozessor 16 zur Ausführung benötigt. Die Zuweisung einer Task zu einem bestimmten Signalprozessor 16, der diese Task behandeln kann, kann entweder vom Host-Prozessor 12 oder vom Skript-Interpreter 32 bewerkstelligt werden.
In der Sprachnachrichtenanwendung werden die Tasks von ankommenden Anrufen gestartet. Ein Beispiel einer Task ist die Beantwortung eines Telephonanrufs. Andere Tasks umfassen das Abhören einer Nachricht, das Aufzeichnen einer Nachricht und dergleichen. In einer Anwendung wie der Sprachnachrichtenverarbeitung ändern sich die Tasks, die der Task der Beantwortung eines Telephonanrufs folgen, entsprechend der Eingabe des Anrufers. Zum Beispiel kann der Anrufer das Abhören von Nachrichten, das Aufzeichnen von Nachrichten, das Erreichen eines Operators und dergleichen anfordern. Daher ist in der Sprachnachrichtenanwendung das Skript der Code, den der Signalprozessor 16 ausführt, sobald ein Telephonanruf beantwortet wird.
Als Beispiel für die Operation der Multitasking-Operation beantwortet eine mögliche Task einen Telephonanruf. Der Host- Treiber 34 führt ein Verbundlesen durch, um den Auswahlsatz zu empfangen, wobei der Host-Prozessor 12 die Bereichsteilmenge, die das Skript für diese Task enthält, an den Signalprozessor 16 liefert. Jede Prozessoreinheit 16, die die Task ausführen kann, interpretiert das Skript und bereitet sich auf dessen Ausführung vor. Wenn das Telephon klingelt, beantwortet der erste verfügbare Prozessor den Anruf. Der nächste Telephonruf wird von einem zweiten Prozessor 16 verarbeitet usw.
Fig. 3 ist ein funktionelles Blockschaltbild des Programmund Datenspeichers des Signalprozessors 16, der im Speicher 17 enthalten ist. Die Programmierung hat drei Hauptbestandteile: einen Ausführungssteuerabschnitt 31, einen Skript- Interpreter-Abschnitt 32 sowie einen Host-Treiberabschnitt 34. Der Ausführungssteuerabschnitt 31 speichert den Code, der vom Signalprozessor 16 ausgeführt wird und vom Host-Prozessor 12 nicht verändert wird. Dieser Code unterstützt Aufrufe für spezielle Funktionen von heruntergeladenen Routinen. Zum Beispiel kann eine heruntergeladene Routine eine Funktion "gen-tone (5)" aufrufen, was anzeigt, daß ein DTMF-Signal gewünscht wird, das dem Tastaturzeichen 5 entspricht. Der Host-Treiber 34 behandelt die E/A zum und vom Host-Prozessor 12 in einer Weise ähnlich der E/A-Handhabung durch einen Normgerätetreiber zu und von einer Peripherievorrichtung wie z. B. einem Plattenlaufwerk. Der Skript-Interpreter-Abschnitt 32 interpretiert die Skripten wie oben erläutert. Wie in Fig. 3 gezeigt, besitzt der Speicher 17 ferner einen Primärspeicherbereich zum Speichern von Programmcode und anderen Daten, die vom Host-Prozessor 12 heruntergeladen werden.
Der Host-Prozessor 12 und der Signalprozessor 16 können jeweils den Zugriff auf ihre jeweiligen Speicher 13 und 17 exklusiv steuern. Somit führt jeder Prozessor 12 und 16 seine eigenen E/A-Operationen aus.
Die Zwischenprozessorkommunikation, insbesondere das Herunterladen vom Host-Prozessor 12 zum Signalprozessor 16, ist in der EP-A-0 474 436 mit dem Titel "Methodfor Communications Between Processors of a Multi-processor System", die dem Anmelder der vorliegenden Erfindung zugeteilt ist, genauer beschrieben. Kurz, der Host-Prozessor 12 kann mit dem Bereich die Daten spezifizieren, die er zum Signalprozessor 16 übertragen will. Der Signalprozessor 16 führt eine Anpassungsleseoperation aus, um die Bereichsdaten zu empfangen. Diese Anpassungsschreib- und Anpassungsleseoperationen ermöglichen den auf einem Signalprozessor 16 laufenden Prozessen, den Zugriff auf einen exklusiven Bereich des Host-Prozessors 12 zu steuern. Indem dem Signalprozessor 16 ermöglicht wird, einen Bereich anzufordern, bevor dieser geliefert werden kann, ist es dem Host-Prozessor 12 nicht möglich, in diesen Bereich zu schreiben, bevor der Signalprozessor 16 das Zugreifen auf denselben beendet hat.
Die Verarbeitungsorganisation wird mittels einer "Verbundlese"-Operation reduziert, die einen Host-Treiber 33 verwendet. Diese Operation erfordert nur eine E/A-Operation je Skript und ermöglicht dem Signalprozessor 16, alle Bereiche, die er benötigt, sofort zu empfangen.
Abgesehen von Effektivitätsbetrachtungen des Herunterladens der Daten für spezielle Tasks ist die Task-Ablaufsteuerung ferner für eine Echtzeitverarbeitung wünschenswert. Ein grundsätzliches Konzept der Erfindung ist das Zuweisen von Verarbeitungseigenschaften zu jeder Task, so daß eine Ablaufsteuervorrichtung eine Ablaufsteuerung auf der Grundlage dieser Eigenschaften ermitteln kann. Diese Eigenschaften umfassen die Frage, wie lange die Verarbeitung dauert und wieviel Speicher für die Verarbeitung erforderlich ist.
Eine der Verarbeitungseigenschaften ist ein "Echtzeit"-Prozessor-Verhältnis, das die Verarbeitungszeit geteilt durch die Datenzeitspanne ist. Zum Beispiel wird angenommen, daß Daten mit 160.000 Abtastwerten je Sekunde für eine Gesamtdatenzeitspanne von 20 ms gelesen werden und die Verarbeitungszeit für diese Datenmenge 5 ms beträgt. Das Prozessor-Verhältnis beträgt 5 / 20 = 25 %. Wenn die Task mehr als 5 ms plus einem "Spielfaktor" benötigt, wird die Verarbeitung nicht als Echtzeitverarbeitung betrachtet. Die erforderliche Verarbeitungszeit für mehr oder weniger Daten kann leicht ermittelt werden.
Die folgende Datenstruktur ist ein Beispiel der Verarbeitungseigenschaften, die von einer Task, die in der Programmiersprache C geschrieben ist, beansprucht wird:

Struct Task_Characteristics

{
long task_type;
long task_degrade_path;
long task_time_max;
long task_id;
long buffer_time;
long average_execution_time;
long total execution time;
long minimum_ execution_time;
long maximum_ execution_time;
long number_ executions;
long number_alarms;
long task_status;
}
Die Datenelemente in dieser Struktur sind wie folgt beschrieben:
task_type identifiziert den Typ der Verarbeitung, die die Task ausführt, z. B. task_type = DTMF_RECEIVER.
task_degrade_path zeigt an, wie eine weniger Betriebsmittel beanspruchende Task herabge setzt wird oder die aktuelle Verarbeitung der Task zu einer weniger Betriebsmittel beanspruchenden Operation geändert wird.
task_time max zeigt die maximale Zeitspanne an, die eine Task benötigen darf, bevor ein Alarm ausgelöst wird.
task_id eine Zahl, die diese Task eindeutig von allen anderen Tasks unterscheidet.
buffer_size definiert die Anzahl der Bytes in allen der Task zugewiesenen Puffern.
buffer_time definiert die Zeitspanne, die von den Daten in den Task-Puffern mit buffer_size dargestellt werden.
average_execution_time statistischer Wert, der die mittlere Zeitspanne anzeigt, die diese Task benötigt, um einen Datenpuffer zu verarbeiten.
total_execution_time statistischer Wert, der die Gesamtzeit anzeigt, die diese Task für die Verarbeitung von Datenpuffern verwendet hat.
minimum_execution_time statistischer Wert, der die kürzeste Zeitspanne anzeigt, die zur Verarbeitung eines Datenpuffers verwendet worden ist.
maximum_execution_time statistischer Wert, der die längste Zeitspanne anzeigt, die zur Verarbeitung eines Datenpuffers verwendet worden ist.
number_executions definiert, wie viele Datenpuffer verarbeitet worden sind.
number_alarms Anzahl der Alarme, die aufgetreten sind, während diese Task ausgeführt worden ist.
task_status aktueller Status dieser Task, z. B. TASK_OK ALARM_ON TASK_KILLED.
Eine Laufzeit-Ablaufsteuerung ist ein Teil der Programmierung jedes Digitalprozessors 16. Diese Ablaufsteuerung verwendet einen Task-Identifizierer, Daten, die die Verarbeitungseigenschaften einer Task darstellen, sowie die Verfügbarkeit der Betriebsmittel. Unter Verwendung dieser Daten weist die Ablaufsteuerung die Betriebsmittel während der Laufzeit für jede Task dynamisch zu und gibt diese frei. Die Verarbeitungseigenschaften werden bei der Initialisierung bestimmt, indem sie vom Host-Prozessor 12 heruntergeladen werden oder wie im folgenden erläutert dynamisch rekonfiguriert werden. Verschiedene Verbesserungen der Erfindung umfassen eine zusätzliche Programmierung zur Handhabung eines Herabsetzungsprozesses, wenn das System überlastet wird, oder zum Führen von Leistungstatistiken.
Während der Initialisierung des Signalprozessorsystems 15 wird Daten- und Stapelraum denjenigen Tasks zugewiesen, die der jeweilige Prozessor 16 auszuführen hat. Die Betriebsmittelzuweisungen werden von der Ablaufsteuerung während der Laufzeit verwendet.
Fig. 4 zeigt Programmierungskomponenten der Ablaufsteuerung und den Laufzeitprozeß der Ablaufsteuerung der Tasks. Die Hauptprogrammierungskomponenten der Ablaufsteuerung sind eine Task-Warteschlange 41, ein Warteschlangenmanager 42, ein Alarmtreiber 43, ein Zeitablaufgenerator 44 sowie ein Überzeit-Manager 45.
Bevor die Verarbeitung beginnt, sind die Tasks A-E in einer Task-Warteschlange 41 enthalten. Eine Anfrage für eine Task gliedert die Task A aus der Task-Warteschlange 41 aus und leitet sie an den Warteschlangenmanager 42 weiter.
Die Task A übergibt anschließend dem Warteschlangenmanager 42 ihre Verarbeitungseigenschaften, die als "beanspruchte Eigenschaften" bezeichnet werden.
Der nächste Schritt für die Behandlung der Task A wird bestimmt durch deren Verarbeitungseigenschaften und die Verfügbarkeit der Systembetriebsmittel. Somit wird in Abhängigkeit davon, welcher Prozessor 16 verfügbar ist, falls einer verfügbar ist, und von den Befriedigungen der Anforderungen der Task A die Task an diesen weitergeleitet. Somit liest der Warteschlangenmanager 42 die beanspruchten Verarbeitungseigenschaften der Task A und ermittelt, welche Betriebsmittel, falls überhaupt, verfügbar sind. In Abhängigkeit von der Verfügbarkeit der Betriebsmittel, die die Anforderungen der Task A erfüllen, weist die Ablaufsteuerung 42 die Task A einem Prozessor 16 zur Ausführung zu oder verzögert die Ausführung.
Wenn die Task A zu laufen beginnt, "aktiviert" sie den Alarmtreiber 43, der die obenbeschriebene Überwachungsfunktion durchführt. Der Zeitablaufgenerator 44 beginnt die Verarbeitung der Task A zu messen. Wenn die Task A die Verarbeitung innerhalb ihrer beanspruchten Zeitspanne abschließt, trägt sie sich aus und der Alarm wird deaktiviert. Für die Task A können Leistungsdaten gesammelt und gespeichert werden. Der vom Zeitablaufgenerator 44 verwendete Zeitgeber kann irgendeine von mehreren wohlbekannten Hardwarezeitsteuerungsvorrichtungen sein.
Wenn jedoch die Task A mehr als ihre beanspruchte Zeitspanne benötigt, sendet der Zeitablaufgenerator 44 ein Unterbrechungssignal zum Prozessor 16. Das Unterbrechungssignal aktiviert eine Alarmdienstroutine 43a, die ein Alarmsignal sendet, um einen Überzeit-Manager 45 zu aktivieren.
Der Überzeit-Manager 45 diagnostiziert den Verarbeitungsstatus der Task A, um zu ermitteln, ob ein Problem wie z. B. ein Speicherkonflikt, eine Endlosschleife, eine Blockierung oder ein beschädigter Stapel eine Verzögerung verursacht. Der Überzeit-Manager 45 ermittelt ferner, wie die Verzögerung aufzulösen ist, indem er z. B. die Task neu einteilt oder indem er den Puffer manipuliert. Der Überzeit-Manager 45 ermittelt ferner, ob die Task einfach eine falsche erwartete Verarbeitungszeit angegeben hat. Der Überzeit-Manager 45 läuft als Task mit hoher Priorität, die vom Alarmsignal aktiviert wird.
Wenn im oben ausgeführten Beispiel die Task A mehr als 5 ms plus einem kleinen "Spiel"-Zeitfaktor benötigt, wird der Alarm aktiviert. Der Überzeit-Manager kann die Pufferstrategie ändern, die Task A anhalten oder die Task A für einen weniger zeitaufwendigen Algorithmus programmieren oder einige andere Verwaltungsentscheidungen durchführen.
Das Versorgen des Überzeit-Managers 45 mit Informationen über die Verarbeitungseigenschaften einer Task ermöglicht einer Task ferner, zeitlich verschoben zu werden. Zum Beispiel ermöglicht das Angeben der RAM-Anforderungen die obenerwähnte Puffermanipulation. Mit anderen Worten, die Task kann zeitlich verschoben werden, wobei ihre Daten gespeichert werden. Da ferner die RAM-Anforderungen in Prozessor-Verhältnis- Zeitspannen ausgedrückt sind, weiß der Überzeit-Manager 45, wie lange der Prozeß für eine gegebene Datenmenge benötigt und wieviel Speicher benötigt wird.
Ein weiteres Merkmal des Überzeit-Managers 45 ist, daß er ein Herabsetzungsschema zur Verfügung stellt, wenn eine Task zeitlich verschoben wird. Zum Beispiel kann der Überzeit- Manager 45 eine Task aufrufen, die hinsichtlich des Prozessor-Verhältnisses weniger aufwendig ist. Diese Task kann dem Benutzer einen alternativen Dienst anbieten, wobei ein vollständiger Zusammenbruch der Dienste vermieden wird. Zum Beispiel kann ein alternativer Dienst die Erzeugung eines Besetzt-Signals sein.
Die Fähigkeit des Ablaufsteuerungssystems zum Überwachen der Verarbeitungseigenschaften der Task, die vom Digitalprozessor 16 ausgeführt werden, ermöglicht, daß diese Eigenschaften während der Laufzeit dynamisch modifiziert werden. Alternativ können diese Eigenschaften separat getestet und dem System zugeführt werden.

Claims

1. Verfahren für die Ablaufsteuerung von Tasks, die von Prozessoren eines Multitasking-Multiprozessorsystems (10) auszuführen sind, mit den folgenden Schritten:

Ausführen eines Anwendungsprogramms, das die Abarbeitung mehrerer Tasks in einer besonderen Reihenfolge erfordert; Bestimmen der Verarbeitungseigenschaften der mehreren auszuführenden Tasks;

Herstellen einer Beziehung zwischen den Tasks und einer Datenstruktur, die die Verarbeitungseigenschaften repräsentiert;

Anordnen der mehreren Tasks in einer Task-Warteschlange (41);

Ausgliedern einer ersten Task der mehreren auf die Abarbeitung wartenden Tasks aus der Warteschlange;

Beanspruchen der Verarbeitungseigenschaften der ersten Task in einem Zeitablaufsteuerprogramm (43);

Auswählen von für die erste Task zu verwendenden Verarbeitungsbetriebsmitteln als Antwort auf die Verarbeitungseigenschaften und verfügbare Betriebsmittel unter Verwendung des Zeitablaufsteuerprogramms (43); und

Aktivieren eines Alarmtreibers (43), wenn die erste Task die Verarbeitungsbetriebsmittel zu nutzen beginnt, und Ausführen einer Zeitsteuerung der Nutzung, um tatsächliche Verarbeitungseigenschaften zu erzeugen;

Aktivieren eines Überzeit-Managers (45), falls die tatsächlichen Verarbeitungs eigenschaften einen vorgegebenen Wert übersteigen, wobei der Überzeit-Manager die Abarbeitung der Task anhält, einen Verarbeitungsstatus der ersten Task diagnostiziert, um festzustellen, ob ein Problem eine Verzögerung verursacht, und, falls ja, bestimmt, wie die Verzögerung zu lösen ist, und bestimmt, ob die Verarbeitungseigenschaften inkorrekt sind; und Wiederholen des Schrittes des Ausgliederns einer Task aus der Warteschlange, des Beanspruchens der Verarbeitungseigenschaften, des Auswählens von Verarbeitungsbetriebsmitteln und des Aktivierens des Alarmtreibers und gegebenenfalls des Überzeit-Managers, bis sämtliche Tasks abgearbeitet worden sind.

2. Verfahren nach Anspruch 1, ferner mit dem Schritt des Vergleichens der beanspruchten Eigenschaften mit den tatsächlichen Eigenschaften.

3. Verfahren nach Anspruch 2, ferner mit dem Schritt des Aktivierens eines Unterbrechungsdienstes, falls die tatsächlichen Eigenschaften die beanspruchten Eigenschaften um einen vorgegebenen Wert übersteigen.

4. Verfahren nach Anspruch 1, ferner mit dem Schritt des Modifizierens der beanspruchten Eigenschaften als Antwort auf die tatsächlichen Eigenschaften.

5. Verfahren nach Anspruch 1, in dem die Verarbeitungseigenschaften ein Prozessornutzungsverhältnis umfassen.

6. Verfahren nach Anspruch 1, in dem der Alarm-Manager alternative Verarbeitungsaktivitäten bestimmt.